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ABSTRACT 


The  purpose  of  the  thesis  is  to  analyze  Marine  Corps  efforts  to  comply  with  the  Joint 
Requirements  Oversight  Council  (JROC)  directive  for  a  single  Joint  Blue  Force 
Situational  Awareness  (JBFSA)  capability.  The  shared  battlespace  is  saturated  with 
stovepipe  digital  situational  awareness  and  command  and  control  systems.  To  ensure 
interoperability  between  ground  forces,  JROC  Memorandum  163-04  (JROC,  2004) 
approved  the  Marine  Corps  and  Army  convergence  strategy  to  adapt  a  single  JBFSA 
capability.  An  incremental  approach  strategy  was  adopted  to  reach  SA  convergence.  Joint 
Capabilities  Release  (JCR)  represents  Increment  I  and  is  currently  being  fielded  to 
operational  units  within  the  Army.  Joint  efforts  are  ongoing  to  develop  and  test  Increment 
II,  Joint  Battle  Command-Platform  (JBC-P).  Both  software  packages  leverage  fielded 
Blue  Force  Tracker  (BFT)  hardware  and  provide  enhanced  capabilities  to  address  JROC 
convergence  directives. 

JCR  and  JBC-P  were  designed  to  coincide  within  the  Army  Battle  Command 
System  (ABCS).  As  a  result,  both  solutions  are  more  Army  centric  than  Marine  Corps 
centric.  Consequently,  mismatches  exist  within  and  beyond  the  software  between  the 
Services.  The  primary  challenge  for  the  Marine  Corps’  team  is  marrying  the  solutions 
with  the  Marine  Air-Ground  Task  Force  (MAGTF)  systems  and  architecture. 
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I.  INTRODUCTION 


A.  JOINT  FORCE  FUNDAMENTALS  OF  THE  UNITED  STATES  ARMED 

FORCES 

Joint  Publication  1  (Joint  Chiefs  of  Staff,  2007)  is  the  keystone  document  that 
establishes  doctrine  for  joint  operations.  The  document  describes  the  present-day 
battlefield  as  ever  changing  and  the  United  States  military’s  adaptability  to  counter  its 
adversaries.  The  document  describes  the  modem-day  battlefield  as  “extremely  fluid  with 
changing  alliances  and  new  threats.  The  United  States  military  is  designed  to  operate 
seamlessly  in  that  environment,  addressing  a  variety  of  challenges,  both  traditional  and 
irregular”  (Joint  Chiefs  of  Staff,  2007,  p.  i).  The  fundamental  concept  in  maintaining  the 
advantage  against  all  challengers  is  fighting  as  a  unified  force.  The  ultimate  goal  of  the 
unified  force  is  to  increase  the  effectiveness  and  lethality  of  available  military  might.  The 
Goldwater-Nichols  Act  of  1986  was  instrumental  in  improving  several  critical  areas 
within  the  Department  of  Defense  (DoD).  One  area  was  focusing  the  Services  from 
independent  operations  to  joint  interest  operations.  One  of  the  key  objectives  was  to 
provide  for  more  efficient  use  of  the  DoD’s  resources  (Goldwater-Nichols  Department  of 
Defense  Reorganization  Act,  1986,  p.  4).  Joint  Publication  1  (Joint  Chiefs  of  Staff,  2007) 
describes  joint  operations  as  “team  warfare.”  Consequently,  “the  synergy  that  results 
from  the  operations  of  joint  forces  maximizes  the  capability  of  the  force.  The  advantage 
of  a  joint  team  extends  beyond  the  battlefield  and  across  the  range  of  military  operations” 
(Joint  Chiefs  of  Staff,  2007,  p.  1-2). 

B.  PROBLEM  STATEMENT 

The  United  States  military  maximizes  its  combat  power  by  fighting  as  a  joint 

force.  However,  within  the  shared  battlespace  the  Services  operate  stovepipe  systems  to 

provide  tactical  situational  awareness  of  their  units.  These  systems  are  not  interoperable, 

which  significantly  increase  the  potential  for  fratricide  occurrences.  The  Marine  Corps 

initiated  efforts  to  comply  with  the  Joint  Requirements  Oversight  Council  (JROC,  2004) 

convergence  directive  by  altering  the  fielding  strategy  of  the  Data  Automated 

Communication  Terminal  (DACT)  variants,  which  was  its  primary  digital  situational 
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awareness/command  and  control  (SA/C2)  system.  Additionally,  in  order  to  communicate 
with  Army  units  sharing  the  battlespace  in  support  of  the  Global  War  on  Terrorism 
(GWOT),  the  Marine  Corps  rapidly  procured  and  fielded  the  Anny’s  SA/C2  solution, 
Force  XXI  Battle  Command  Brigade  and  Below — Blue  Force  Tracker  (FBCB2-BFT). 
Consequently,  the  Marine  Corps  relies  on  the  Army’s  infrastructure  and  resources  to 
operate  the  systems.  The  Army  maintains  the  L-Band  satellite  network,  architecture,  and 
resources  required  to  operate  FBCB2-BFT  within  the  current  Global  War  on  Terrorism 
(GWOT)  region.  However,  the  resources  are  limited  outside  that  region  and  may  be 
unavailable  for  Marine  forces  conducting  traditional  expeditionary  missions.  Moreover, 
the  planned  upgrade  to  the  FBCB2  system,  designated  as  Joint  Capability  Release  (JCR), 
represents  Increment  I  towards  interoperability,  but  its  software  and  hardware  capabilities 
have  not  proven  fully  capable  of  meeting  Marine  Corps  operational  requirements. 
Additionally,  reasonable  concerns  exist  in  developing,  testing,  and  concept  of 
employment  (COE)  for  Increment  II,  Joint  Battle  Command-Platform  (JBC-P).  Both 
enhanced  capabilities  are  essentially  designed  towards  the  Army  Battle  Command 
System  (ABCS).  They  mandate  an  overly  complex  architecture  that  is  dependent  on 
organic  ABCS  resources  that  do  not  reside  within  the  Marine  Air-Ground  Task  Force 
(MAGTF)  architecture.  Furthermore,  testing  revealed  an  overarching  lack  of  a  reliable 
network  for  SA/C2. 

C.  PURPOSE 

The  purpose  of  the  thesis  is  to  provide  an  analysis  of  Marine  Corps  efforts  to 
comply  with  the  JROC  convergence  directive  for  a  Joint  Blue  Force  Situational 
Awareness  (JBFSA)  capability  for  ground  forces.  The  Army’s  FBCB2-BFT  solution  was 
first  fielded  to  Marine  Corps  units  during  preparation  for  Operation  Iraqi  Freedom.  Since 
that  time,  the  system  has  been  widely  fielded  throughout  the  Marine  Corps.  The  system 
has  clearly  been  a  force  multiplier  in  the  combat  zone  and  as  a  result  the  Marine  Corps 
SA  program  of  record,  DACT,  has  been  deemed  obsolete  by  leadership. 

This  research  provides  insight  into  the  actions  taken  by  the  Marine  Corps  towards 
convergence.  This  research  highlights  complexities  of  this  joint  effort,  to  include 
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imbalance  in  resources,  priorities,  and  capabilities  between  the  Army  and  Marine  Corps. 
Additionally,  this  research  provides  some  considerations  and  recommendations  for 
further  study. 

D.  RESEARCH  QUESTION 

The  primary  intent  of  the  JROC  is  to  reduce  redundancy  and  increase 
commonality  between  the  Services.  This  research  will  address  the  primary  question;  why 
are  the  current  convergence  efforts  not  as  favorable  towards  Marine  Corps 
implementation  as  the  Army?  In  addition,  how  important  is  it  for  all  players  to  have 
equal  influential  power  and  resources  on  joint  efforts? 

E.  METHODOLOGY 

The  Marine  Corps  and  Army  have  separate  requirements  documents  for  their 
respective  digital  SA/C2  systems.  These  requirements  and  corresponding  parameters 
were  used  to  evaluate  the  initial  new  capability,  which  proved  to  be  impractical.  An 
endeavor  was  undertaken  to  develop  a  joint  Capabilities  Development  Document  (CDD) 
for  the  objective  solution.  The  research  methodology  focuses  on  evaluating  the  directive 
to  develop  and  field  a  JBFSA  capability  at  all  echelons.  This  was  accomplished  through  a 
quantitative  content  analysis  of  program-related  materials.  Data  collection  was  achieved 
via  confidential  in-person  interviews  with  personnel  from  the  Army  and  Marine  Corps 
program  offices.  The  interviews  were  conducted  at  the  individual  program  office  site  and 
were  recorded,  transcribed,  and  then  analyzed  for  relevance  and  accuracy.  The 
participants  interviewed  provided  adequate  factual  infonnation  on  the  history  and 
ongoing  efforts,  but  opinions  were  not  solicited.  Additional  data  was  collected  through 
analysis  of  test  reports,  Joint  Capabilities  Integration  and  Development  System 
documents,  and  other  related  program  documents  for  amplifying  infonnation. 
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F.  ORGANIZATION  OF  THE  THESIS 

Chapter  II,  Background,  provides  a  brief  history  of  the  Services’  specific  digital 
SA  capabilities,  oversight  council  directives  that  initiated  Marine  Corps  involvement  with 
the  Anny’s  platform  and  dismounted  SA  solution,  and  the  Marine  Corps’  Blue  Force 
Tracker  Family  of  Systems  program. 

Chapter  III  examines  the  incremental  approach  to  reach  SA  convergence.  It  also 
provides  analysis  of  each  increment’s  capabilities  and  test  and  evaluation  efforts. 

Chapter  IV  provides  considerations  from  the  analysis  of  Increment  I  and 
Increment  II. 

Chapter  V  provides  recommendations  for  further  research  to  better  determine 
Increment  II  feasibility  of  fielding  to  the  Marine  Corps  and  analysis  of  Blue  Force 
Tracker  use  in  Marine  Corps  expeditionary  operations  other  than  war. 
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II.  BACKGROUND 


This  chapter  provides  a  brief  history  of  the  Services’  specific  digital  SA 
capabilities,  the  oversight  council  directives  that  initiated  Marine  Corps  involvement  with 
the  Army’s  platform  and  dismounted  SA  solution,  and  the  Marine  Corps’  Blue  Force 
Tracker  Family  of  Systems  program. 

The  U.S.  Marine  Corps  and  Anny  have  traditionally  employed  diverse,  friendly 
force  tracking  capabilities  to  enhance  their  respective  battlefield  situational  awareness.  At 
the  onset  of  Operation  Iraqi  Freedom  (OIF),  a  number  of  stovepipe  systems  were 
operated  by  each  Service.  The  various  systems  were  extremely  reliable  and  effective  but 
not  interoperable.  Each  system  transmitted  its  respective  fonn  of  position/location 
information  (PLI)  data  to  the  joint  task  force  level,  via  the  Joint  Global  Command  and 
Control  System  (GCCS-J)  server,  which  then  populated  the  higher  echelon  common 
operating  picture  (COP).  At  the  lower  echelon,  the  Marine  Corps  used  Command  and 
Control  Personal  Computer  (C2PC)  and  the  Anny  used  Maneuver  Control  System-Light 
(MCS-L)  1  to  display  the  COP  (Stengrim,  2005,  p.  4).  The  systems  were  incapable  of 
sharing  infonnation  directly  due  to  different  architectures  (Stengrim,  2005,  p.  4). 

A.  MARINE  CORPS  DIGITAL  SITUATIONAL  AWARENESS  AND 

COMMAND  AND  CONTROL  CAPABILITIES 

At  the  initial  stage  of  OIF,  DACT  and  the  Miniature  Transmitter  (MTX)  were  the 
primary  digital  SA/C2  tactical  systems  employed  by  Marine  forces. 

The  DACT  is  the  Marine  Corps’  program  of  record  for  tactical  Blue  Force 
tracking  and  situational  awareness.  DACT  provides  a  two-way  path  (send  and  receive) 
for  PLI,  messaging,  and  chat.  The  DACT  operates  on  the  Enhanced  Position  Location 
Reporting  System  (EPLRS)  classified  network  that  is  limited  to  line-of-sight  (LOS) 
terrestrial  transmission.  The  DACT  capability  was  fielded  as  vehicle-mounted  (M- 
DACT)  and  hand-held  dismounted  (D-DACT)  variants.  The  following  are  excerpts  from 
the  DACT  Operational  Requirements  Document  (ORD)  Change  3  (Marine  Corps  Combat 
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Development  Command,  2001),  signed  January  8,  2001,  that  explains  the  requirements, 
key  perfonnance  parameters  (KPP),  and  related  operational  parameters  for  the  system. 


The  DACT  shall  provide  automated  communications  support  for 
commanders  in  tactical  operations.  This  automation  expedites  existing 
manual  decision-making  and  executing  processes,  in  addition  to  the 
processes  associated  with  planning,  processing  combat  infonnation,  and 
the  exercise  of  tactical  direction.  The  DACT  will  be  used  to  transmit, 
receive,  store,  retrieve,  create,  modify,  and  display  map  overlays  and 
commanders’  critical  information  requirements  (CCIRs).  The  DACT  will 
exchange  this  information  with  other  users  of  the  Tactical  Data  Network 
(TDN).  Other  units’  positions,  coordinates  of  user-designated  points,  pre¬ 
formatted  messages  and  free-text  information  are  CCIRs  managed  by  the 
DACT.  Tactical  communications  such  as  radio  network  and  local  area 
networks  (LANs)  will  be  the  systems  that  enable  DACT  generated  data  to 
be  transmitted  between  users.  Using  global  positioning  information,  and 
digital  maps  resident  on  the  removable  disk,  the  DACT  will  provide  a 
screen  display  of  its  own  position  location,  (p.  1)  . . . 

The  KPPs  for  the  DACT  consist  of  the  ability  to  display  a  map  with  GPS 
derived  position  location  information  (PLI)  [Interoperability  KPP] 
represented  on  the  map,  the  ability  to  transmit  PLI  generated  by  the  DACT 
to  a  C2PC  Gateway  and  receive  PLI  from  a  C2PC  Gateway,  and  transmit 
and  receive  those  messages  in  Appendix  D.  The  dismounted  DACT  shall 
be  interoperable  with  UHF,  VHF  and  HF  voice/data  radios  that  are  man- 
portable  and  mounted  in  tactical/armored  vehicles.  This  maintains  the 
requirement  to  exchange  preformatted  and  free  text  messages  on  point-to- 
point  and  netted  doctrinal  radio  nets.  (Marine  Corps  Combat  Development 
Command,  2001,  p.  3) 

The  DACT-generated  PLI  data  is  transmitted  to  GCCS-J  by  the  Intelligence  and 
Operations  Workstation  (IO W)  functioning  as  a  C2PC  Gateway  located  in  the 
commander’s  Combat  Operations  Center  (COC).  Figure  1  depicts  the  DACT  System 
Interface  Diagram. 
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Figure  1.  DACT  System  Interface  Diagram  (From  Marine  Corps  Combat  Development 

Command,  2001,  p.  34) 

The  MTX  is  a  beacon  limited  to  one-way  communication  that  provides  the 
capability  to  identify  position  and  track  progress  (Stengrim,  2005,  p.  5).  The  MTX 
primarily  supported  Marine  Corps  Special  Operations  Command  ground  forces. 
However,  a  limited  number  of  devices  were  provided  to  the  Marine  Aircraft  Wing 
(MAW)  to  support  rotary  platforms  operating  in  the  theater  of  operations.  The  device 
transmits  PLI  only;  it  has  no  messaging  function.  The  position  information  generated  by 
devices  mounted  on  air  assets  was  pushed  to  the  Marine  Tactical  Air  Command  Center 
(TACC)  via  C2PC.  The  MAW  operated  the  MTX  as  a  short-term  solution  until  the 
Aviation  BFT  fielding. 
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The  DACT  and  MTX  limitations  disqualified  both  systems  as  viable  solutions 
towards  JBFSA.  Only  a  limited  number  of  Marine  Corps  forces  had  either  capability  at 
the  onset  of  OIF.  Figure  2  depicts  M-DACT,  D-D  ACT,  and  MTX  systems. 


MTX 


Figure  2.  M-DACT,  D-DACT,  and  MTX  Systems  (From  Product  Manager,  Digital 

Fires  Situational  Awareness  [DFSA],  2010) 

B.  U.S.  ARMY  FBCB2-BFT 

The  Army’s  program  of  record  for  digital  Blue  Force  tracking  and  situational 
awareness  is  FBCB2.  FBCB2  provides  a  two-way  (send/receive)  path  for  PLI  and  is 
messaging  and  chat  capable.  FBCB2  was  developed  in  two  different  versions  to  utilize 
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available  EPLRS  and  L-Band  satellite  networks,  FBCB2-EPLRS  and  FBCB2-BFT, 
respectively.  The  L-Band  network  enables  flexible  and  beyond-line-of-sight 
communications.  The  satellite  network  utilizes  commercial  encryption.  Consequently, 
FBCB2  has  a  National  Security  Agency-approved  classification  of  sensitive  but 
unclassified.  The  FBCB2  Program  Management  Office  (PMO)  is  a  component  of  the 
Program  Executive  Office  Command  Control  and  Communications  Tactical  (PEO  C3T). 
FBCB2-BFT  is  a  multi-Service,  Army  Acquisition  Category  1C,  post-Milestone  C 
program. 

The  remainder  of  this  section  relies  heavily  on  Conatser  and  Grizio’s  (2005) 
Master  of  Business  Administration  professional  report.  The  report  provides  a 
comprehensive  analysis  on  the  genesis,  history,  and  employment  of  FBCB2  within  the 
Army. 

The  FBCB2  capabilities  had  a  modest  beginning. 


In  2000,  the  Balkan  Digitization  Initiative  effort  in  both  Bosnia  and 
Kosovo  was  the  genesis  for  BFT.  About  600  systems  had  been  used  with 
the  commercial  Fieldworks/Kontron  and  Ku  Band  using  a  reduced 
functionality  FBCB2  software  Version  3.1.  The  maturity  level  of  FBCB2 
software  provided  an  effective  Graphic  User  Interface  (GUI),  a  variety  of 
functional  command  and  control  messaging  capabilities,  a  robust  mapping 
capability,  graphic  control  measure  development  and  symbology.  Finally, 
hardware  development  under  the  FBCB2  program  baseline  and 
procurement  under  Low  Rate  Initial  Production  (LRIP)  provided  a  partial 
hardware  solution  to  install.  The  ability  to  leverage  L-Band  transceivers 
from  a  pre-existing  Movement  Tracking  System  contract  was  the  final 
hardware  component  required  to  complete  the  system,  (p.  35) 

The  FBCB2  system  was  battle  tested,  which  led  to  follow-on  deployment  in 
support  of  Global  War  on  Terrorism. 

The  initiative  that  culminated  with  the  development  and  fielding  of  the 
FBCB2-BFT  system  actually  evolved  over  time  and  was  one  of  three 
technical  initiatives  to  increase  command  and  control  in  the  theater  of 
operations.  The  broad  effort  to  support  United  States  Central  Command 
(CENTCOM)  began  in  February  2002,  and  was  threefold,  as  follows:  1) 

Correct  current  communications  and  network  problems  within  the  theater 
of  operations,  2)  Design  and  build  a  command  center  for  the  integration  of 
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all  fielded  ABCS  Systems,  and  3)  Field  200  “tracking  systems”  within  the 
Afghanistan  theater  of  operations.  (Conatser  &  Grizio,  2005,  p.  33) 

System  fielding  to  combat  units  in  support  of  Global  War  on  Terrorism  operations 
was  expedited.  Leadership  realized  it  was  vital  for  some  level  of  commonality  between 
the  multinational  force  to  increase  SA  and  reduce  the  occurrences  of  friendly  fire. 
Additionally,  FBCB2  increased  combat  efficiency. 

The  2d  Brigade  Combat  Team  (BCT),  3d  Infantry  Division  (ID)  was 
deployed  to  Kuwait  in  September  and  October  2002  for  Operation  Desert 
Spring  (formerly  Intrinsic  Action)  and  was  the  first  unit  to  receive 
FBCB2-BFT.  What  followed  was  an  unprecedented  fielding  of  FBCB2- 
BFT  systems  in  Army  Pre-positioned  Stocks  (APS)  and  unit  platforms  in 
theater,  as  well  as  on  unit  platfonns  at  home  station  prior  to  their 
deployment.  This  resulted  in  simultaneous  installation  of  more  than  1,000 
systems  on  three  continents,  spanning  six  countries,  including  20  states 
within  the  United  States,  and  involving  more  than  a  dozen  Army,  Joint, 
and  Coalition  formations.  Throughout  this  process,  over  4,000  soldiers 
were  trained.  The  system  was  provided  to  the  3d  ID  (M);  1st  Armored 
Division;  101st  Air  Assault  Division;  82d  Airborne  Division;  2d  Light 
Cavalry  Regiment;  3d  Armored  Cavalry  Regiment;  173d  Airborne 
Brigade;  3d  Brigade,  4th  ID  (M);  75th  Exploitation  Task  Force;  11th 
Aviation  Brigade;  12th  Aviation  Brigade;  1st  Marine  Expeditionary  Force 
(MEF);  and  the  1st  United  Kingdom  Armored  Division,  as  well  as  selected 
V  Corps  and  Coalition  Forces  Land  Component  Command  (CFLCC) 
platforms  and  command  posts,  (p.  38)  ... 

FBCB2-BFT  provided  Operation  Enduring  Freedom  and  Iraqi  Freedom 
commanders  and  units  a  remarkable  capability  that  greatly  enhanced  their 
combat  effectiveness.  FBCB2-BFT  enabled  the  ability  to  navigate  under 
limited  visibility  conditions,  to  move  rapidly  over  great  distances  and 
synchronize  unit  movement,  and  to  communicate  both  vertically  and 
horizontally  over  extended  distances.  Unit  Commanders’  initial 
confidence  in  the  system  varied.  It  is  difficult  to  embrace  a  new  system 
and  discard  tried  and  true  practices  with  which  they  and  their  units  were 
familiar  and  confident.  In  some  cases,  units  were  forced  to  accept,  and 
came  to  rely  on,  FBCB2-BFT  when  traditional  equipment  and  accepted 
practices  proved  insufficient  during  the  campaign.  During  Operations 
Enduring  Freedom  and  Iraqi  Freedom,  the  level  of  FBCB2-BFT’s 
effectiveness  and  individual  unit  “digital  learning  curves”  varied  after 
receiving  the  system.  Units  that  quickly  embraced  the  new  technology  and 
placed  command  emphasis  on  its  training  and  employment,  benefited  early 
on  in  the  campaign.  Others  that  either  received  the  capability  late  in  the 
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fielding  process  or  did  not  quickly  embrace  it,  were  forced  to  adjust  during 
the  conflict.  (Conatser  &  Grizio,  2005,  p.  41) 

The  Army  strategically  fielded  the  FBCB2-BFT  variant,  as  compared  to  the 
EPLRS  variant,  in  greater  numbers  among  its  tactical  combat  units  in  Iraqi  and 
Afghanistan.  Army  senior  leadership  understood  the  scope  of  the  operating  area  and  the 
nature  of  the  environment  in  which  GWOT  operations  would  predominantly  take  place. 
Combat  operations  would  be  conducted  in  austere,  restricted,  and  vast  areas  where 
combat  units  would  exceed  the  LOS  limits  of  the  EPLRS  network.  Satellite 
communications  are  not  limited  to  the  same  restrictions  of  the  EPLRS  network.  Both 
FBCB2  variants  were  mounted  exclusively  on  High  Mobility  Multipurpose  Wheeled 
Vehicle  (HMMWV)  platforms. 

1.  FBCB2  Architecture 

The  Network  Operations  Center  (NOC)  is  the  central  point  in  the  FBCB2 
network.  FBCB2-generated  digital  data  is  pushed  to  the  NOC  via  L-Band  Satellite  and 
ground  station.  The  NOC  integrates  and  disseminates  to  all  active  BFT  systems  via 
reverse  path.  FBCB2  uses  commercial  type  encryption.  Consequently,  the  network  is  a 
one-way  feed  to  the  joint  environment.  FBCB2  PLI  is  transmitted  to  GCCS-J  through  a 
radiant  mercury  guard  located  at  the  NOC.  Marine  Corps  COC  pull  data  from  GCCS-J 
via  JTCW.  Marine  Corps  PLI  is  classified  and  cannot  transmit  to  FBCB2.  The  radiant 
mercury  guard  is  there  to  prohibit  secret  information  from  passing  to  the  network.  Figure 
3  depicts  the  FBCB2  data  flow. 
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Figure  3.  FBCB2  Data  Flow  (From  Product  Manager,  DFSA,  2010  ) 

C.  OVERSIGHT  COUNCIL  DIRECTIVES 


Fratricide  has  always  existed  on  the  battlefield.  Studies  have  shown  that 

technological  advances  have  significantly  reduced  occurrences.  In  the  initial  stages  of 

OIF,  fratricide  accounted  for  about  11%  of  United  States  battlefield  deaths,  as  compared 

to  24%  during  Desert  Storm  over  a  decade  earlier  (Cahlink,  2004).  It  was  widely 

understood  that  the  lack  of  battlefield  SA  was  a  major  factor  for  the  occurrences.  In  June 

2003,  the  JROC  ordered  the  development  of  the  framework  to  enhance  combat 

effectiveness  and  improve  interoperability  between  the  ground  forces  (JROC,  2003). 

JROC  Memorandum  (JROCM)  161-03  (JROC,  2003)  requested  the  Army  and  USMC 

provide  an  integrated  briefing  to  the  JROC  discussing  the  way  ahead  towards  converging 

efforts  for  achieving  a  single  Joint  capability.  In  2004,  to  ensure  interoperability  between 

the  Army  and  USMC,  JROCM  163-04  (JROC,  2004)  approved  the  Marine  Corps  and 

Army  convergence  plan  to  adapt  a  single  capability.  The  JROC  approved  the  plan  to 

make  FBCB2  the  capability  baseline,  assigned  the  U.S.  Army  as  the  lead  Service  to 
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develop  the  JBFSA  capability,  and  directed  the  Marine  Corps  to  adopt  FBCB2-BFT  for 
its  platform  and  dismounted  applications  (JROC,  2004).  Marine  Requirements  Oversight 
Council  (MROC)  Decision  Memorandum  (DM)  41-2004  (MROC,  2004),  dated  June  2, 
2004,  establishes  the  MROC  concurrence  with  the  recommendation  to  migrate  to  the 
FBCB2  baseline  as  the  Marine  Corps  refreshes  its  dismounted  and  mounted  devices. 
However,  the  MROC  desired  for  the  Marine  Corps  to  “remain  independent  and  maintain 
its  own  communication  architecture”  (MROC,  2004). 

D.  MARINE  CORPS  AND  FBCB2-BFT 

In  late  2002,  Marine  Corps  and  Army  tactical  units  had  limited  methods  to  readily 
communicate  with  each  other.  To  prepare  for  OIF,  I  Marine  Expeditionary  Force 
submitted  an  Urgent  Universal  Needs  Statement  (UUNS)  to  acquire  50  vehicle-mounted 
FBCB2-BFT  systems  to  communicate  with  Army  ground  units  sharing  the  battlespace. 
The  units  immediately  recognized  the  advantages  of  the  FBCB2-BFT  capability  as  a 
force  multiplier.  Marine  forces’  operational  requirement  for  FBCB2-BFT  rose 
significantly  after  the  onset  of  the  GWOT.  The  system  provided  maneuver  forces  with  the 
ability  to  communicate  and  exchange  critical  combat  information  and  messages  with 
adjacent  units  utilizing  same  system.  Subsequent  to  the  initial  UUNS, 
MARCORSYSCOM  responded  to  multiple  UUNS  and  initiatives  requesting  FBCB2- 
BFTs  for  deployed  units. 

•  March  2003,  UUNS  requested  267  systems  to  support  convoy  operations. 

•  January  2004,  UUNS  requested  100  systems  to  directly  support  combat 
operations. 

•  September  2004,  UUNS  requested  26  systems  to  directly  support  combat 
operations. 

•  FY05  Supplemental  Initiative,  to  procure  2600  systems  to  mitigate 
shortfalls  of  forces  supporting  GWOT. 

•  FY05  Marine  Corps  Forces  Central  Command  (MARCENT)  requirement, 
requested  1826  systems  as  part  of  a  multisystem  integrated  effort  for 
Ml  1 14  HMMWVs  supporting  OIF. 
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In  November  2008,  representatives  from  the  BFT  PMO  and  support  contractors 
deployed  to  locations  in  Kuwait  and  Afghanistan  to  conduct  a  field  assessment  of  the 
Marine  Corps’  BFT  effort  in  support  of  Operation  Enduring  Freedom  (OEF)  ramp  up. 
The  objective  of  the  trip  was  to  improve  the  logistical  and  operational  support  to  Marine 
forces.  The  assessment  concluded  that  the  Marine  Corps  was  a  burden  on  the  Anny’s  in¬ 
theater  contracted  logistical  support  network  and  continued  support  was  unsustainable  for 
the  long  term.  A  Marine  Corps  BFT  Service  Center  was  established  in  Kuwait  to  support 
MARCENT  combat  requirements  for  both  the  Iraq  and  Afghanistan  theaters. 
Additionally,  all  BFT-equipped  vehicles  transitioning  from  Iraq  to  Afghanistan  were 
refurbished  at  the  service  center  in  order  to  upgrade  the  combat  strained  systems. 
Moreover,  plans  were  coordinated  with  stakeholders,  including  Marine  Corps  Logistic 
Command,  to  establish  BFT  Field  Service  Representative  (FSR)  sites  onboard  Camp 
Kandahar,  Camp  Leatherneck,  and  follow-on  forward  operating  bases. 

At  the  height  of  combat  operations,  the  Marine  Corps  had  19  dedicated  BFT 
FSRs.  The  FSRs  were  strategically  positioned  aboard  each  major  Marine  Corps  operating 
base  within  theater  and  in  the  continental  United  States  (CONUS).  The  FSR  conducted 
maintenance,  installations,  and  over- the- shoulder  training  to  all  Marine  Corps  units 
utilizing  BFT  systems. 

1.  Memorandum  of  Agreement  with  Stakeholders 

A  Department  of  the  Anny  memorandum  of  agreement  (MOA;  Department  of  the 
Army,  Program  Executive  Office  Command,  Control,  and  Communications  Tactical 
[PEO  C3T],  2004)  between  the  Army,  the  Marine  Corps,  and  the  United  States  Special 
Operations  Command  (USSOCOM)  “established  an  enduring  partnership  among  the 
Services  and  solidified  the  roles  directed  by  the  JROC  for  achieving  a  single,  joint 
capability”  (p.  2).  Additionally,  the  MOA  recognized  program  Manager  (PM),  FBCB2  as 
servicing  agency  and  allowed  the  Marine  Corps  access  to  existing  Anny  contracts  to 
procure  and  support  FBCB2-BFT.  The  Army  was  able  to  economically  procure  FBCB2- 
BFT  systems  and  services  by  combining  the  requirements  of  all  Services  and 
subsequently  purchasing  in  economically  advantageous  quantities.  The  result  was  a 
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decrease  in  the  per-unit  cost  and  substantial  savings  to  the  government,  savings  that  could 
not  have  been  realized  through  smaller  purchases  made  independently.  Both  the  Army 
and  the  Marine  Corps  realized  cost  avoidance  by  combining  their  respective  FBCB2-BFT 
system  requirements,  enabling  both  Services  to  benefit  from  the  quantity  discounts 
provided  in  Army  contracts.  Moreover,  each  saved  additional  funds  by  conducting  joint 
system  integration  and  testing  and  combining  logistical  services  support,  thereby 
avoiding  the  cost  duplication  that  inevitably  occurs  when  like  items  are  procured 
separately.  More  important,  utilizing  already  established  Army  contract  vehicles  enabled 
the  Marine  Corp  to  efficiently  and  expeditiously  meet  its  FBCB2-BFT  requirements  in 
support  of  home  station  training  and  overseas  contingency  operations. 

2.  Marine  Corps  BFT  Program  Management  Office 

For  the  Marine  Corps,  the  FBCB2-BFT  capabilities  are  referred  to  as  the  BFT 
Family  of  Systems  (FoS).  The  BFT  FoS  is  a  product  line  within  the  JBC-P  FoS  portfolio. 
The  JBC-P  FoS  is  defined  as  a  weapon  system  program  with  a  product  line  made  up  of 
systems  and  products  associated  with  the  BFT  FoS  (Increment  I)  and  JBC-P  (Increment 
II).  The  PMO  resides  within  MARCORSYSCOM.  The  BFT  FoS  is  the  primary  digitized 
battlefield  COP  component  of  the  Marine  Air-Ground  Task  Force  (MAGTF)  C2 
infrastructure  for  echelons  below  the  battalion  level.  The  BFT  FoS  is  comprised  of  the 
vehicle-mounted  BFT,  the  dismounted  Tactical  Operations  Center  (TOC)  Kit,  and 
FBCB2  software.  In  addition  to  the  systems  procured  and  delivered  in  support  of  GWOT, 
to  date  the  BFT  PMO  has  procured  4,000  FBCB2-BFT  systems.  Supporting  combat  zone 
requirements  is  a  priority,  but  the  PMO  made  the  BFT  FoS  readily  available  to  all  Marine 
Corps  units  in  CONUS,  Hawaii,  and  Okinawa.  The  systems  supported  home  station 
readiness  and  pre-deployment  training  requirements.  Figure  4  depicts  the  BFT  FoS 
systems. 
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Figure  4.  TOC  Kit  and  HMMWV  Mounted  BFT  (From  Product  Manager,  DFSA,  2008 

a.  Blue  Force  Tracker 

The  BFT  system  consists  of  the  JV-5  computer,  12-inch  display, 
interconnecting  cables,  MT-201 1  series  L-Band  satellite  transceiver,  a  Defense  Advanced 
Global  Positioning  System  Receiver  (DAGR),  and  an  installation  kit  appropriate  to  the 
host  vehicle  type.  The  Deputy  Commandant  (DC),  Combat  Development  and  Integration 
(CD&I;  2007)  Letter  of  Clarification  {LOC)  established  the  interim  procurement  BFT 
objective  at  8,549.  The  objective  was  based  on  emerging  requirements  and  to  support  the 
Marine  Corps’  convergence  strategy  (CD&I,  2007).  In  both  OIF  and  OEF  theaters,  BFT 
systems  were  installed  on  various  platforms,  including  the  HMMWW  family  of  vehicles 
(FoV),  Light  Armored  Vehicle  FoV,  Medium  Tactical  Vehicle  Replacement,  Logistics 
Vehicle  System  Replacement,  and  M88  Recovery  Vehicle.  Figure  5  depicts  the  BFT  core 
components. 
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Figure  5.  BFT  Core  Components  (From  Product  Manager,  DFSA,  2008) 


b.  Tactical  Operations  Center  Kit 

The  TOC  Kit  is  the  BFT  variant  that  brings  blue  force  SA  capability  into 
the  MAGTF  COC.  The  TOC  Kit  consists  of  a  CF-30  laptop,  MT-2011,  DAGR,  and 
interconnecting  cables.  The  DC,  CD&I  LOC  (2007)  established  the  interim  procurement 
TOC  Kit  objective  at  562. 

c.  FBCB2  Software 

The  FBCB2  software  is  the  initial  baseline  software  that  enables  ground 
units  to  exchange  large  volumes  of  C2,  SA,  and  PLI.  Additionally,  the  software  enables 
operators  to  send  and  receive  C2  messages  and  overlays.  The  current  fielded  version  is 
FBCB2  6.5. 
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E. 


SUMMARY 


This  chapter  provided  the  reader  with  background  infonnation  on  Marine  Corps 
and  Army  specific  digital  SA  capabilities  and  the  oversight  council  directives  that 
mandated  convergence. 
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III.  INCREMENTAL  APPROACH 


This  chapter  will  describe  the  incremental  approach  strategy  to  achieve  SA  convergence. 
Additionally,  it  will  provide  an  analysis  of  each  increment’s  capabilities  and  test  and 
evaluation  efforts. 

A.  INCREMENT  I— JOINT  CAPABILITIES  RELEASE 

1.  Overview 

JCR  is  the  upgrade  to  the  FBCB2  system.  The  software  developer  is  Northrop 
Grumman,  in  Carson,  CA.  Initial  fielding  of  FBCB2  occurred  over  a  decade  ago,  but  this 
rugged  system  still  remains  the  primary  digital  battlefield  tactical  SA/C2  solution.  JCR 
brings  enhanced  capabilities  that  are  force  multipliers  to  the  warfighter:  Two  of  these 
capabilities  address  critical  issues  that  exist  in  the  current  system;  latency  and 
information  security.  The  improved  capabilities  include  a  new  transceiver  to  support  a 
high-speed  satellite  communications  network  and  a  programmable  in-line  encryption 
device  that  supports  Type  1  data  encryption.  The  PM  FBCB2  JCR  Test  and  Evaluation 
Strategy  briefing  (U.S.  Army  Office  of  the  Program  Manager,  FBCB2  [PM  FBCB2], 
2010)  states  that  the  software’s  primary  purpose  is  to  “allow  forces  to  simultaneously 
mount,  execute,  and  recover  from  operations  and  synchronize  all  of  the  operating 
systems”  (p.  8).  Additionally,  the  briefing  states  JCR  improves  C2  “while  on  the  move  by 
receiving  and  updating  the  situation  awareness  via  net-centric  linkages  between  Tactical 
Operational  Centers  (TOCs)  and  net-centric  links  between  mounted  and  future  JBC-P 
systems”  (PM  FBCB2,  2010,  p.  8).  In  fiscal  year  (FY)  2011,  the  Anny  began  fielding 
JCR  to  operational  units  in  CONUS  and  in  the  Republic  of  Korea.  The  Marine  Corps  will 
begin  fielding  to  units  during  their  pre-deployment  training,  in  the  third  quarter  of 
FY2013.  The  JCR  software  version  1.3. 1.4  is  the  official  Marine  Corps’  fielding 
candidate.  Moreover,  JCR  represents  the  interim  solution  (Increment  I)  towards  JROC- 
directed  SA  convergence. 
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2.  Capabilities 


a.  BFT  2  Network/T ramceiver 

The  new  faster  satellite  network  is  known  as  BFT  2.  The  current  system  is 
plagued  with  latency  and  its  transceiver  is  half-duplexed.  Consequently,  friendly  position 
updates  take  minutes  and  send/receive  messages  are  limited  to  single  transmission  (one 
way  at  a  time).  The  BFT  2  network  provides  10  times  the  bandwidth  as  compared  to  the 
existing  network.  The  new  transceiver  is  full-duplex  and  enables  simultaneous 
send/receive  transmissions.  With  its  enhanced  capabilities,  the  system  is  capable  of 
updating  friendly  positions  and  transmits  messages  in  seconds.  Therefore,  the  warfighter 
will  be  able  to  share  more  vital  battlefield  information  to  more  users  and  do  it  faster. 
Additionally,  the  increased  data  capacity  improves  the  accuracy  of  friendly  SA  and  the 
depiction  of  reported  enemy  locations,  obstacles,  and  known  battlefield  hazards.  The 
following  excerpt  is  from  the  BFT  2  PowerPoint  (PM  FBCB2,  2011)  brief  that  provides 
more  details  on  BFT  2. 

The  BFT  2  upgrade  program  will  enhance  performance  for  BFT 
transceivers  in  both  the  ground  and  air  domains.  The  next  generation  BFT 
2  network  provides  near  global  coverage  (70°N  to  70°  S)  and  operates  over 
geosynchronous  L-Band  satellites  (e.g.,  Inmarsat-3,  Inmarsat-4,  Artemis, 
and  Thuraya).  The  BFT2  network  consists  of  two  active  and  one  backup 
Satellite  Network  Control  Centers  (SNCC),  up  to  eight  (8)  Satellite 
Ground  Stations  (SGS),  and  supports  up  to  200,000  remote  Ground 
Vehicular  Transceivers  and  Aviation  Transceivers.  Each  SNCC  connects 
with  the  SGSs  through  a  redundant  terrestrial/Very  Small  Aperture 
Terminals  (VSAT)  network.  A  SGS  interoperates  with  BFT-2 
Transceivers  in  a  star  topology.  A  BFT  2  air  interface  designed  to  meet 
capacity  and  latency  requirements  allows  the  SGS  and  BFT  2  Transceivers 
to  exchange  Joint  Variable  Message  Format.  (PM  FBCB2,  201 1,  p.  3) 

b.  KGV-72  Encryption  Device 

The  KGV-72  is  a  new  programmable  in-line  encryption  device  (PIED) 
that  encrypts  BFT-generated  data  Type  1,  under  the  classification  “secret.”  The  device 
resides  between  the  system  processor  and  GPS  transceiver.  The  KGV-72  is  the  solution 
to  provide  the  warfighter  a  seamless,  classified  network.  Additionally,  the  KGV-72 
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abides  by  JROC  policy  for  classified  friendly  battlefield  information  (JROCM  071-08) 
and  National  Security  Agency  Type  1  certification  requirements. 

c.  Additional  Capabilities 

JCR  provides  an  abundance  of  additional  capabilities  to  BFT  operators. 
The  following  list  of  capabilities  was  gained  from  in-person  interviews  with  PM  FBCB2 
senior  leadership  and  a  PowerPoint  brief  provided  by  the  PMO  (Program  Office,  FBCB2, 
2010). 

•  Marine  Corps  EPLRS  Interoperability — provides  Marine  Corps 
network  with  a  terrestrial  capability 

•  JCR  Logistics  (Log;  C2/SA  Interoperability) — allows  exchange  of 
C2/SA  between  JCR  Log  and  JCR  Vehicle 

•  C2  Repository  (C2R) — server  that  allows  use  of  the  Address  Book 
Database 

•  Self-Descriptive  SA  (SDSA) — removes  requirement  for  large 
preplanned  databases  and  allows  users  to  log  in  and  send  an  SDSA 
message  with  all  necessary  information  (i.e.,  Unit  Reference 
Number,  Internet  Protocol  address)  to  update  C2R.  Allows  BFT- 
equipped  units  to  change  task  organizations  in  the  field  to  meet 
new  mission  requirements 

•  Recognition  of  Combat  Vehicles — allows  recognition  of  combat 
vehicles  training  tool 

•  Graphical  User  Interface/Commercial  Joint  Mapping  Toolkit — 
pennits  new  map  types 

•  Data  Dissemination  Service  (DDS) — allows  data  flow  to  GCCS-J 

•  Secure  Mission  Data  Loader  (MDL) — provides  encryption  of  data 
on  MDL,  connects  to  Windows  and  Linux 

•  Slew-to-cue — allows  JCR  operator  to  auto  send  message  to 
Vehicle  Commander  for  shoot/no  shoot  detennination 

•  Open  Office — allows  writer,  calculations  and  impress  applications 
on  system,  compatible  with  Microsoft  Office 

•  Personal  File  Folder — allows  for  easy  file  management 

•  Enhanced  Imagery — allows  images  to  be  sent/received 

•  CENTCOM  Regional  Intelligence  Exchange  System  International 
Security  Assistance  Force — allows  exchange  of  data  with  coalition 
forces  in  Afghanistan 
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3. 


Architecture 


The  JCR  network  architecture  is  complex.  The  Network  Operations  Center 
(NOC)  remains  the  backup  node  to  data  flow.  Three  NOCs  are  geographically  segmented 
for  redundancy.  Redundancy  is  built  in  the  network  for  seamless  transition  from  one 
NOC  to  another,  in  the  event  one  is  degraded.  Celestial  JCR-generated  PLI  and  messages 
are  the  same  as  the  current  FBCB2-BFT.  Data  are  pushed  to  the  NOC  via  L-Band 
Satellite  and  ground  station.  The  NOC  integrates  and  disseminates  to  all  celestial  JCR 
systems  via  reverse  path.  There  are  two  new  systems  required  with  JCR,  the  DDS  server, 
and  C2R.  C2R  enables  SDSA  and  DDS  enables  interoperability  to  the  joint  community. 
The  DDS  located  in  the  NOC  (NOC  DDS)  distributes  to  another  DDS  server  located  in 
the  Combatant  Command  (COCOM)  TOC.  The  DDS  at  the  COCOM  pushes  to  GCCS-A, 
which  continues  the  path  to  GCCS-J,  and  then  to  the  MAGTF  architecture.  The  data  flow 
reverses  for  terrestrial  data  generated  via  Marine  Corps  systems.  The  data  flow  is 
seamless  with  the  new  BFT  2  network  and  occurs  in  a  matter  of  seconds.  Figure  6  depicts 
the  JCR  data  flow.  Figure  7  depicts  the  JCR  concept  of  employment. 
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Figure  6.  JCR  Data  Flow  (From  Product  Manager,  DFSA,  2010) 
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Figure  7.  JCR  Concept  of  Employment  (From  Product  Manager,  DFSA,  2010) 
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4. 


Test  and  Evaluation 


This  section  relies  heavily  on  in-person  interviews  with  the  JBC-P  FoS  PMO 
leadership  and  SPA  WAR  test  result  documents. 

The  Marine  Corps  joined  the  Army’s  JCR  test  paradigm  in  FY2005.  Since  that 
time,  JCR  underwent  an  intensive  test  and  evaluation  (T&E)  process.  The  Marine  Corps’ 
test  strategy  is  aligned  with  the  Army’s.  Joint  test  events  are  conducted  to  maximize 
resources  and  better  assess  mutual  requirements.  When  necessary,  the  Marine  Corps 
team  conducts  independent  testing  for  specific  Marine  Corps  requirements.  The  JBC-P 
FoS  PMO  established  three  mutually  supported  sites  with  dedicated  personnel  to 
assess  each  JCR  software  build.  A  limited  Initial  Test  Team  (ITT)  augmented  the  Army’s 
test  team,  which  was  collocated  with  the  software  developer  Northrop  Grumman. 
This  ITT’s  primary  mission  was  to  test  Marine  Corps  specific  requirements  in  each 
software  release.  More  comprehensive  teams  are  located  in  Charleston,  SC,  within  the 
Space  and  Naval  Warfare  Systems  Center  (SPAWAR)  Atlantic  and  aboard  Marine 
Corps  Base  (MCB)  Camp  Pendleton,  CA,  within  the  Marine  Corps  Tactical  Systems 
Support  Activity  (MCTSSA).  The  SPAWAR  facility  is  the  Marine  Corps’  JBC-P 
FoS  Increment  I  Configuration  Manager  (CM).  MCTSSA  is  a  component  of 
MARCORSYSCOM.  The  MARCORSYSCOM  webpage  identifies  MCTSSA  as  the 
Marine  Corps  “organization  for  integration,  interoperability,  and  technical  support  for 
tactical  Command,  Control,  Communication,  Computer,  and  Intelligence  (C4I)  systems” 
(marcorsyscom.marines.mil).  Both  sites  are  tasked  with  conducting  all  Increment  I  and 
Increment  II  development  testing  efforts. 

a.  Requirements 

The  DACT  Operational  Requirements  Document  (ORD;  Marine  Corps 
Combat  Development  Command,  2001)  and  direction  from  DC,  CD&I  were  the  basis  for 
the  requirements  and  parameters  used  to  evaluate  JCR: 

•  System  shall  display  100%  SA  (PLI)  accuracy  within  a  15-minute 
window  (based  on  refresh  rate); 

•  System  shall  send/receive  messages  within  5  minutes; 
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•  Systems  will  demonstrate  the  ability  to  display  a  map  with  GPS- 
derived  PLI  represented; 

•  System  must  transmit/receive  PLI  data  with  C2PC  Gateway 
(shows  interoperability  with  Joint  Tactical  COP  Workstation 
[JTCW]);  and 

•  System  must  transmit  and  receive  preform  Variable  Message 
Format  (VMF)  messages. 

b.  Events 

Each  software  version  and  subsequent  release  underwent  identical  series 
of  joint  test  events.  System  Subsystem  Acceptance  Testing  (SSAT)  is  the  first  in  the  test 
series.  SSAT  is  a  formal  lab  acceptance  test  of  the  software.  SSAT  is  conducted  to  verify 
the  ability  of  the  software  to  meet  system  requirements  and  readiness  for  formal  testing 
(PM  FBCB2,  2011).  The  developer  formally  delivered  to  the  government  each  JCR 
software  release  to  the  ITT.  The  ITT  conducted  all  SSATs  within  controlled  spaces  at  the 
developer  facility.  After  successful  completion  of  the  SSAT,  the  software  build  was  sent 
to  the  Central  Testing  Support  Facility  (CSTF),  Fort  Hood,  TX.  The  CTSF  then  built  the 
Marine  Corps’  hard  disk,  referred  to  as  the  gold  brick.  The  gold  brick  was  then  sent  to  the 
SPA  WAR  facility. 

Risk  Reduction  Event  (RRE)  is  second  in  the  test  series.  The  purpose  of  the  RRE 
was  to  verify  and  validate  the  JCR  capabilities’  functionality  in  the  planned  Marine 
Corps/Army  architecture.  The  RREs  were  conducted  at  both  comprehensive  test  sites. 
The  Army  tested  out  of  the  CSTF.  The  RREs  were  executed  in  four  phases,  in  numerical 
order.  Phases  I  and  II  were  perfonned  at  SPAWAR.  When  the  initial  phases  were 
completed,  multiple  hard  disks  were  duplicated  and  sent  to  MCTSSA  for  subsequent 
testing.  Phases  III  and  IV  were  simultaneously  executed  by  both  test  sites  and  the  CTSF, 
utilizing  the  Defense  and  Research  Engineering  Network  (DREN).  The  DREN  supports 
DoD-wide  research,  development,  testing,  and  evaluation  activities.  The  vast  majority  of 
DT  events  were  completed  on  the  DREN.  During  each  phase,  data  were  collected  on  the 
interactions  between  the  architectures,  overall  system  perfonnance,  and  compliance  with 
the  DACT  ORD  requirements.  In  addition,  Phase  I,  II,  and  III  tests  are  completed  to 
check  hardware  functions,  system  configuration,  and  standalone  operations.  Moreover, 
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Phase  III  and  IV  tests  are  performed  to  verify  the  system  can  accurately  transmit  and 
receive  data  throughout  a  Marine  Corps  representative  network.  All  phases  were 
performed  on  the  BFT  FoS  loaded  with  JCR  software,  to  verily  the  software  satisfied  the 
testable  software  requirements  set  forth  in  the  DACT  ORD  (Marine  Corps  Combat 
Development  Command,  2001).  Test  cases  were  developed  using  specific  DACT  ORD 
requirements  to  evaluate  the  system  to  support  each  test  phase.  Each  test  case  was 
completed  and  assessed  with  pass,  pass  with  exception,  or  fail  (SPAWAR,  Atlantic, 
201 1,  p.  3).  Only  after  successful  completion  of  each  RRE  would  the  software  move  to  a 
formal  field  test  (FT)  or  field  user  evaluation  (FUE). 

Appendix  A  is  an  excerpt  of  RRE  test  cases  from  the  SPAWAR  RRE  9  Test 
Report  (SPAWAR,  Atlantic,  2011).  Included  is  the  attribute  support  for  the  specific 
DACT  ORD  Capability  and  the  criteria  used  to  assess  each  attribute. 

At  the  completion  of  each  test  day,  a  meeting,  referred  to  as  a  hotwash,  was 
conducted  with  all  test  participants.  The  hotwash  discussed  issues  encountered  including 
test  case  discrepancies  and  other  software  and  system  deficiencies.  A  consolidated  list 
was  generated,  evaluated,  and  prioritized  based  on  severity.  The  list  was  provided  to  the 
software  developer  as  a  Software  Change  Request  (SCR).  The  developer  normally  would 
release  a  software  patch  to  adjudicate  the  SCRs.  SCR  fixes  that  could  not  be  resolved 
with  a  patch  would  be  included  in  a  follow-on  software  release,  engineered  to  address  the 
deferred  SCR  fixes. 

Third  on  the  test  series,  and  more  often  accomplished  concurrently  and 
throughout  DT,  were  the  Joint  Interoperability  Test  Command  (JITC)  certification 
(combined  Army  and  USMC  certification)  and  risk  assessment.  The  JTIC  certification 
process  was  accomplished  by  representatives  from  the  Defense  Infonnation  Systems 
Agency  (DISA).  The  certification  not  only  included  an  evaluation  of  information 
exchanges  and  the  interfaces  used  to  support  those  exchanges,  but  also  included  the 
JITC’s  evaluation  of  the  elements  of  the  Net  Ready  KPP  (PM  FBCB2,  201 1,  p.  3-2).  The 
JTIC  evaluation  was  based  upon  requirements  identified  in  the  JCR  Information  Support 
Plan  (ISP)  and  Interoperability  Certification  Evaluation  Plan  (ICEP).  The  risk 

assessments  were  comprised  of  the  information  assurance  (IA)  requirements.  The  JBC-P 
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Test  and  Evaluation  Master  Plan  (TEMP)  describes  the  assessments  as  “designed  to 
reduce  the  risks  due  to  the  threat  of  computer  network  attack.  Software  vulnerabilities 
and  poor  system  configuration  constitute  avenues  for  unauthorized  access  to  the  system, 
manipulation  or  theft  of  data,  and  denial  of  service”  (PM  FBCB2,  201 1,  p.  3-2). 

Field  Test  (FT)  is  a  joint  event  using  limited  resources.  The  Marine  Corps  Test 
Team  supported  each  FT  in  the  controlled  lab  spaces  of  each  test  site  with  desktop 
systems  and  test  support  contractors.  The  Anny  executed  each  FT  with  support 
contractors  and  soldiers. 

The  Marine  Corps  and  Army  conducted  specific  DT  events  to  evaluate  JCR.  The 
Army  changed  the  way  it  evaluated  and  test  networked  capabilities  for  the  ABCS. 
Network  Integration  Events  (NIE)  are  a  semi-annual  combined  evaluation  of  systems  that 
will  be  coupled  and  fielded  to  soldiers  as  part  of  a  capability  set:  These  events  were 
aimed  to  reduce  the  amount  of  time  and  number  of  resources  necessary  to  field  the 
systems.  The  Army  states  that  the  NIE  “assesses  potential  network  capabilities  in  a  robust 
operational  environment  to  determine  whether  they  perform  as  needed,  conform  to  the 
network  architecture  and  are  interoperable  with  existing  systems”  (bctmod.army.mil). 

Field  User  Evaluations  (FUE)  is  specific  to  the  Marine  Corps  test  strategy  and 
normally  executed  concurrently  with  the  NIE.  The  FUE  were  limited  in  scope  and 
resources,  but  they  included  Marines  operating  JCR-equipped  fixed  and  vehicle-mounted 
BFT  systems.  The  Marines  were  formally  trained  and  individually  filled  C2  roles  in  the 
Marine  Division.  The  FUEs  were  executed  in  simulated  operational  settings  (training 
areas)  aboard  MCB  Camp  Pendleton.  Scenarios  were  developed  and  executed  under  the 
supervision  of  a  test  director  (Marine  Corps  infantry  field  grade  officer).  The  scenarios 
reflected  real  operational  situations  to  validate  system  capabilities  and  interoperability.  At 
the  conclusion  of  each  FUE,  the  Marines  provided  vital  feedback  via  surveys  and 
questionnaires.  Moreover,  the  Marine  Corps  used  a  FUE  for  an  operational  assessment  of 
the  JCR  capabilities. 

Additionally,  the  Anny  team  conducted  events  similar  to  the  scope  of  an  FUE, 
called  Customer  Test  (CT)  and  Fimited  User  Test  (EUT).  Each  event  utilized  various 
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numbers  of  soldiers,  test  personnel,  and  fixed/mounted  systems.  The  Army  relied  on  its 
LUTs  for  an  operational  assessment  of  the  JCR  capabilities  towards  fielding.  The  JBC-P 
FoS  PMO  conducted  an  FUE  in  conjunction  with  each  Army  CT/LUT.  The  nonnal 
sequence  of  tests  to  evaluate  JCR  was  SSAT,  RRE,  JITC/risk  assessment,  and  then 
FUE/LUT/CT/FT/NIE  (dependent  on  the  scope  of  the  operating  force  support  and  test 
objective). 


c.  Results 

The  Marine  Corps  formally  began  JCR  testing  in  August  2009  during 
RRE5.  Statistics  were  kept  on  C2  (message  completion/transmits)  and  SA  (PLI  sharing 
with  the  Joint  COP).  Percentages  were  calculated  based  on  time  available  divided  by  total 
test  time.  Figure  8  depicts  the  C2/SA  results  for  all  Marine  Corps  test  events.  Test  results 
were  not  initially  favorable  for  a  number  of  reasons. 

•  The  software  did  not  support  the  desired  level  of  Marine  Corps 
requirements.  As  a  result,  the  vast  majority  of  the  priority  SCRs 
generated  at  each  hotwash  was  Marine  Corps  related. 

•  C2R  did  not  support  the  concept  of  operations  developed  to  inject 
Marine  Corps  address  book  data  in  the  Tactical  Data 
Communications  Network  (TDCN)  environment.  The  team  had  a 
10%  success  rate. 

•  VMF  was  incompatible  with  JTCW. 

•  Unlike  the  Marine  Corps,  the  Army  did  not  evaluate  JCR 
independently.  Each  event,  other  than  SSATs,  was  a  multisystem 
(with  multiple  PMOs)  test.  There  were  no  less  than  12  systems 
testing  collectively,  simulating  the  Army  Battle  Command  System 
(ABCS),  headed  by  ATEC.  However,  there  was  neither 
configuration  control  nor  a  single  point  of  contact.  Each  system 
executed  separate  test  plans.  Consequently,  systems  would  drop  off 
the  grid  in  the  middle  of  the  test  period,  which  adversely  impacted 
the  already  complex  architecture.  For  instance,  numerous  times 
DDS  would  be  down  for  maintenance  without  notification.  If 
proper  shut  down  procedures  were  not  followed,  null  tracks  would 
populate  the  architecture. 

•  Low  SA  uptime  percentages  reflected  the  reliability  of  the 
connection  between  the  NOC,  DDS,  and  GCCS-A  in  a  complex 
network  architecture.  Unit  Task  Organization  corruption  was  the 
leading  C2  issue. 
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Event  Date  SW  Version  XCVR 

C2  1  SA 

RRE5 

Aug  09 

1.1.1 

BFT  1 

35.0% 

0.0% 

FT  1 

Oct  09 

1.1.4 

BFT  1 

55.0% 

18.4% 

RRE6 

MarlO 

1.1.4 

BFT  1 

69.0% 

0.0% 

RRE  7 

Oct  10 

1.3 

BFT  1 

54.4% 

27.0% 

FUE  1 

Dec  10 

1.3. 1.1 

BFT  1 

89.0% 

38.0% 

FT  2 

Feb  11 

1.3. 1.1 

BFT  1 

40.0% 

37.0% 

RRE  8 

April 

1.3. 1.2 

BFT  2 

88.0% 

12.0% 

FUE  2 

Jun  11 

1.3. 1.2 

BFT  2 

83.0% 

39.2% 

Arch.  Test 

Oct  11 

1.3. 1.2 

BFT  2 

N/A 

83.2% 

RRE  9 

Oct  11 

1.3. 1.3 

BFT  2 

95.2% 

93.8% 

FUE  3 

Nov  11 

1.3. 1.3 

BFT  2 

75.8% 

88.3% 

RRE  10 

Mar  12 

1.3. 1.4 

BFT  2 

100% 

80.1% 

SIPR  Event 

May  12 

1.3. 1.4 

BFT  2 

87.6% 

93.2% 

Figure  8.  Calculated  C2/SA  (From  Product  Manager,  DFSA,  2011 


The  test  team  worked  furiously  with  their  Army  counterpart  to  gain  a  better 
understanding  of  the  issues  and  to  address  potential  challenges.  Additionally,  a  Data 
Exposure  Working  Group  was  established  that  included  members  from  the  FBCB2, 
Mission  Command,  and  JBCP  FoS  PMOs.  The  group’s  objectives  were  to  work  through 
the  issues  identified  by  the  test  team,  identify  problem  areas,  and  develop  and 
recommend  solutions.  As  a  result  of  the  multipronged  effort,  the  following  resolutions 
were  implemented. 

•  New  tactics,  techniques,  and  procedures  (TTPs)  were  developed  to  support 
the  data  flow. 

•  Procedures  were  included  in  the  field  service  bulletin  that  published  the 
proper  system  maintenance  sequence. 

•  Vital  processes  were  documented  and  proven. 

o  The  Marine  Corps  address  book  was  uploaded  to  the  C2R  server, 
o  The  Marine  Corps’  Unit  Task  Organization  was  downloaded  from 
the  C2R  server. 

o  Both  JCR  Terrestrial  and  JCR  Celestial,  with  KGV-72,  were 
configured  and  operated  properly. 

•  DC,  CD&I  redefined  how  JCR  was  to  be  evaluated. 
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The  Increment  II  SA  thresholds  were  used  instead  of  the  ones 
listed  in  the  DACT  ORD  (originally  100%  SA  at  all  times,  now 
only  75%  PLI  of  the  platforms  in  immediate  battlespace  and  50% 
in  the  extended,  which  changed  how  the  percentages  would  be 
calculated). 

•  The  developer  included  main  Marine  Corps  fixes  in  follow-on  software 
releases  that  made  the  software  more  stable. 


Once  all  the  changes  were  implemented,  there  were  significant  improvements  in 
the  C2/SA  percentages  (reference  Figure  8,  after  FUE  2).  More  important,  all  future  tests 
were  under  configuration  management  with  better  communication  between  test  personnel 
for  the  different  systems.  It  was  understood  that  each  event  was  a  system-of-systems  test 
and  joint  effort. 

Leadership  from  the  PMO,  Marine  Corps  Operational  Test  and  Evaluation 
Activity  (MCOTEA),  and  DC,  CD&I  met  on  a  number  of  occasions  with  their  Army 
counterparts  to  discuss  the  way  ahead  for  JCR.  The  Marine  Corps  stakeholders 
determined  a  specific  Marine  Corps  operational  test  (OT)  was  not  necessary.  The 
leadership  considered  a  number  of  reasons  before  making  the  decision. 

•  The  Director,  Operational  Test  and  Evaluation  (DOT&E)  had  approved 
the  executed  combined  PM  FBCB2  Updated  JCR  Test  and  Evaluation 
Strategy  (2010),  with  capstone  events  (i.e.,  FT,  FUE,  and  LUT)  to  support 
the  Army  fielding  decision.  These  events  included  a  combination  of  field 
test,  limited  user  test,  and  field  user  evaluations. 

•  Field  Test  2  (FT2) 

■  The  purpose  of  FT2  was  to  conduct  a  structured,  controlled,  and 
formally  evaluated  field  test  within  an  operational  architecture 
using  soldiers  and  mission-based  test  conduct  to  obtain 
performance  and  reliability  data  on  JCR  version  1.3.1. 

■  The  objectives  were  to  evaluate 

•  C2  and  SA  performance, 

•  soldier  management  of  the  network, 

•  initialization  (platform  and  NOC)  and  the  JCR  database, 

•  Type  1  encryption  measures,  and 

•  Service  interoperability  between  the  different 
communication  paths: 
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o  Celestial  to  Terrestrial, 
o  the  ABCS  and  backward  compatibility,  and 
o  Army  and  Marine  Corps  platforms. 

o  Limited  User  Tests  (in  conjunction  with  FUE  2  and  3) 

■  The  supporting  units  were  3rd  Brigade,  1st  Armored  Division,  1- 
41  Infantry  Battalion,  and  elements  from  1st  Marine  Expeditionary 
Force  equipped  with  JCR  version  1.3.1. 

■  The  evaluation  objectives  were  the  following: 

•  support  the  FBCB2-JCR  fielding  decision; 

•  assess 

o  Entirely  new  software  code,  but  with  the  same 
basic  function  as  previously; 
o  The  new  database  structure  and  SA  process 
(SDSA); 

o  The  improvements  made  to  the  L-Band  Network 
Operations  Center; 

o  The  Type  1  encryption  device;  and 
o  Total  system  information  assurance; 

•  address  outstanding  issues  from  previous  test  events  such 
as 

o  Celestial  to  Terrestrial  interoperability, 
o  Network  configuration  and  management, 
o  Classified  messaging,  and 
o  Reliability  of  the  platform  integrations; 

•  evaluate  training  and  maintainability;  and 

•  demonstrate  interoperability  with  the  joint  community. 

•  JCR  underwent  a  robust  DT  strategy  and  its  capabilities  have  proven  more 
capable  than  envisioned. 

•  The  JBC-P  FoS  PMO  exhausted  its  resources  towards  DT  and  completed 
multiple  FUEs. 

•  The  JCR  software  matured  and  test  results  remained  consistent  with 
expectations. 

•  MCOTEA  observed  all  DT  events  and  provided  the  PMO  with  an 
operational  assessment  of  the  JCR  capabilities. 

•  Initial  JITC  Message  Conformance  Test  (MCT)  was  conducted  in  August 
2011  at  the  MCTSSA  site.  Many  trouble  reports  were  generated  and 
provided  to  the  developer.  Fixes  were  included  with  follow-on  software 
patches  that  resolved  the  most  critical  issues.  The  MCT  was  redone  to 
verify  resolutions  of  the  priority  areas. 
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The  following  section  relies  heavily  on  the  JBC-P  FoS  JCR  NIE  12.2  Test  Report 
(SPAWAR,  Atlantic,  2012a)  provided  by  the  JBC-P  PMO. 

The  test  team  evaluated  the  JCR  capabilities  on  the  operational  Secret  Internet 
Protocol  Router  Network  (SIPRNET).  The  test  plan  was  developed  to  verify  and  validate 
JCR  functionality  in  the  planned  USMC  and  Army  architecture  on  the  live  operational 
network  (SPARWAR,  Atlantic,  2012a,  p.  4).  The  SIPR  Event  was  conducted  at  the 
MCTSSA  site  in  conjunction  with  NIE  12.2  (Army  unit  at  Fort  Bliss,  TX).  The  Marine 
Corps’  JCR  fielding  software  solution,  version  1.3. 1.4,  was  evaluated  within  the  live 
architecture.  The  Texas  A&M  University  (n.d.)  security  webpage  describes  the 
SIPRNET: 

The  SIPRNET  is  the  Department  of  Defense’s  largest  network  for  the 
exchange  of  classified  information  and  messages  at  the  SECRET  level.  It 
supports  the  Global  Command  and  Control  System,  the  Defense  Message 
System,  and  numerous  other  classified  warfighting  and  planning 
applications.  Although  the  SIPRNET  uses  the  same  communications 
procedures  as  the  Internet,  it  has  dedicated  and  encrypted  lines  that  are 
separate  from  all  other  communications  systems.  It  is  the  classified 
counterpart  of  the  Unclassified  but  Sensitive  Internet  Protocol  Router 
Network  (NIPRNET),  which  provides  seamless  interoperability  for 
unclassified  combat  support  applications  and  controlled  access  to  the 
Internet. 

Test  cases  were  generated  to  focus  on  functionality  and  interoperability  between 
the  Anny  and  the  Marine  Corps.  The  test  was  executed  for  80.75  hours.  Both  SA  and  C2 
uptimes  exceeded  the  thresholds  (SA  75.25  hours  [93.2%  of  total  time]  and  C2  70.75 
[87.6%]).  During  this  evaluation,  issues  with  C2  and  SA  were  experienced  by  the  team. 
However,  swift  coordination  with  subject-matter  experts  at  the  CTSF  and  NOC  identified 
and  resolved  the  issues.  Two  of  the  major  issues  were  related  to  SA  flow  from  the  DDS 
and  pulling  the  unit  task  organizations  from  C2R.  The  following  excerpts  are  from  the 
SPAWAR  NIE  12.2  Test  Report  (SPAWAR,  Atlantic,  2012a)  that  describes  the  two 
issues  and  resolutions. 

The  team  discovered  that  DDS  peering  issues  contributed  to  a  majority  of 
SA  loss  between  USMC  terrestrial  and  celestial  systems.  DDS  developers 
located  at  CTFS  and  APG  resolved  the  issues  when  they  occurred.  Other 
contributing  factors  to  SA  loss  were  due  to  IOS  and  GCCS-J  CST 
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corruptions.  The  team  was  required  to  request  additional  ports  from  the 
Marine  Corps  Network  Operations  and  Security  Center  (MCNOSC)  on 
SIPR  for  CST  connections  between  CTSF  and  MCTSSA.  There  were  two 
contributing  factors  to  the  loss  of  C2.  [The]  first  issue  was  with  the  NOC 
C2  gateway  crashing.  These  instances  were  observed  on  three  occasions 
during  this  evaluation.  The  NOC  has  submitted  an  SCR  for  a  fix 
(SCR  T25962).  On  May  22nd,  the  NOC  applied  a  hot  fix  that  resolved  this 
issue.  Further  instances  of  the  NOC  C2  Gateway  cashes  were  not  observed 
following  the  application  of  the  hot  fix.  The  second  contributing  factor  to 
loss  of  C2  for  USMC  systems  was  due  to  routing  issues  between 
MCTSSA  and  APG.  Network  engineers  added  the  necessary  route  to  both 
routers  to  enable  C2  traffic  to  traverse  the  network. 

Issues  were  encountered  when  the  team  attempted  to  pull  Army  UTO 
datasets  from  C2R  via  the  MRC  UTO  application.  Working  with  C2R  and 
JCR  developers,  the  team  found  that  certificates  issued  from  the  C2R  FSR 
for  MRC  systems  were  not  properly  authenticating  with  C2R.  The 
pennissions  set  on  the  “key  store”  certificate  and  “trust  store”  certificate 
were  set  to  “root”  when  permissions  needed  to  be  set  for  the  “C2Rservice” 
accessing  the  certificates.  The  issue  highlighted  a  certificate  distribution 
issue  between  USMC  and  Army  that  prompted  discussing  between  both 
project  offices.  (SPAWAR,  Atlantic,  2012a,  p.  7) 

Figure  9  is  the  cumulative  list  of  all  the  SIPR  Event’s  test  cases  completed  with 
their  status. 


33 


Test  Case 

Status 

1.1  Map  Accuracy 

PASS 

1 .2  Map  Scale 

PASS 

2.1  VMF  Messages 

PASS 

3.1  Overlay  Transmit  and  Receive 

PASS 

4.1  PLI  Completeness 

PASS 

4.2  Average  Time  for  Updates 

PASS 

4.3  PLI  Display 

PASS 

5.1  Verrify  Interoperability 

PASS 

6.1  Purging  GPS  Key 

PASS 

6.2  Remotely  Purging  the  Systems 

PASS 

7.1  Chat  Capability 

PASS 

USA:  1.1  C2R  Load  of  USMC  Role  Data 

PASS 

USA:  1 .2  USMC  Initialization 

PASS 

USA:  3.1  USMC  Terrestrial  to  USMC  Celestial  (C2) 

PASS 

USA:  4.3.1  USMC  Terrestrial  to  USMC/Army  Celestial  (SA) 

PASS 

USA:  4.3.2  USMC/Army  Celestial  to  USMC  Terrestrial  (SA) 

PASS 

USA:  6.1  Adding  Army  Role  Data  to  USMC  Address  Book  Through  Hook 

PASS 

USA:  6  2  USMC  C2R  Pull  of  Army  SDSA 

PASS 

USA:  17.1  NOC  DDSto  CORE  DDS  Network  Loss 

PASS 

USA:  17.2  Restart  of  GCCS-A  COP  Zone 

PASS 

USA:  17.3  Clearing  of  GCCS-A  PLI 

PASS 

USA:  17.4  DDS  Clears  GCCS-A  Topics 

PASS 

USA:  17.5  Restart  of  USMC  BNJTCW 

PASS 

USA:  17.6  Restart  of  USMC  HHQ IOS 

PASS 

USA:  17.7  USMC  REGT  IOS  to  HHQ  IOS  Network  Loss 

PASS 

USA:  17.8  Restart  of  USMC  REGT  IOS 

PASS 

USA:  17.9  Clearing  of  HHQ  IOS  PLI 

PASS 

USA:  17.10  USMC  REG  JTCW  Network  Loss 

PASS 

USA:  17.1 1  Restart  of  USMC  REG  JTCW 

PASS 

USA:  17.12  USMC  BNJTCW  Network  Loss 

PASS 

USA:  17.13  Restart  of  USMC  BN  JTCW 

PASS 

USA:  17.14  Clearing  of  REG  JTCW  PLI 

PASS 

USA:  17.15  Attempt  to  Create  the  USMC  "Null"  Track 

PASS 

Figure  9.  Cumulative  Test  Cases  (From  SPAWAR,  Atlantic,  2012a) 


The  SIPR  Event  was  the  last  Marine  Corps-declared  JCR  test  event  to  evaluate  its 
operational  effectiveness.  For  all  future  DT  events,  JCR  will  be  evaluated  on  a  limited 
basis,  primarily  to  assess  compatibility  with  the  Increment  II  capabilities. 
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B.  INCREMENT  II— JOINT  BATTLE  COMMAND-PLATFORM 

1.  Overview 

Joint  Battle  Command-Platform  (JBC-P)  is  the  next  generation  FBCB2  system. 
The  JBC-P  is  an  Anny-led  Acquisition  Category  (ACAT)  II  program  designated  by  the 
Joint  Requirement  Oversight  Council  (JROC)  as  having  joint  interest.  The  system 
supports  the  Tier  1  Joint  Capability  Areas  of  Joint  C2,  Joint  Battlespace  Awareness,  and 
Joint  Net-Centric  Operations  (Marine  Corps  Systems  Command,  2012,  p.  9).  JBC-P 
achieves  digital  infonnation  (C2  and  SA)  interoperability,  vertically  and  horizontally 
between  joint  warfighting  elements  in  current  and  future  operating  environments.  JBC-P 
will  leverage  BFT  FoS  hardware  and  add  capabilities  to  include  handheld  devices  and 
beacon  systems.  JBC-P  capabilities  increase  accuracy  and  density  of  SA  to  further 
mitigate  risk  of  fratricide.  Additionally,  the  system  increases  the  efficiency  of  orders 
transmission;  graphical  overlays;  and  friendly,  hostile,  neutral,  unknown,  and  non- 
combatant  SA  (SPAWAR,  Atlantic,  201 1,  p.  3).  The  system  improvements/enhancements 
will  answer  JROC  convergence  directives. 

The  PEO  C3T  is  the  Milestone  Decision  Authority  (MDA)  for  the  JBC-P 
program.  The  MDA  officially  initiated  JBC-P  software  development,  and  the  program 
entered  the  acquisition  cycle  at  MS  B  in  September,  2009  (Department  of  the  Army,  PEO 
C3T,  2009).  The  program  received  MS  C  approval  on  July,  17,  2012  (Department  of  the 
Army,  PEO  C3T,  2012).  Commander,  MARCORSYSCOM  is  the  Program  Decision 
Authority  (PDA)  for  the  Marine  Corps,  as  a  participating  service.  PDA  ADM  (Marine 
Corps  System  Command,  2011)  “authorizes  the  Marine  Corps  continued  participation  in 
the  Army’s  program.”  MARCORSYSCOM  manages  the  program  as  the  JBC-P  Family 
of  Systems  (FoS).  The  PMO  is  comprised  of  Increment  I  (BFT  FoS)  engineers, 
logisticians  (government  and  support  contractor),  and  JBC-P  specific  engineering  team. 
The  JBC-P  FoS  Life  Cyle  Cost  Estimate  (Marine  Corps  Systems  Command,  2012) 
describes  the  JBC-P  FoS  as  the  following: 

[A]  Weapon  System  program  with  a  product  line  made  up  of  systems  and 
products  formerly  associated  with  the  Blue  Force  Tracker  (BFT)  FoS 
(Increment  I)  and  JBC-P  (Increment  II).  The  United  States  Marine  Corps 
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(USMC)  is  participating  in  the  U.S.  Army  (USA)  JBC-P  program  under 
the  authority  of  the  Commander,  Marine  Corps  Systems  Command 
(MCSC)  and  will  not  be  entering  into  an  acquisition  milestone  decision 
process.  The  term  JBC-P  FoS  encompasses  both  Increment  I  and 
Increment  II.  Increment  I  consists  of  JCR  software,  BFT  mounted 
systems,  Tactical  Operations  Center  (TOC)  Kits,  the  improved  BFT-2 
transceiver,  and  the  KGV-72  National  Security  Agency  (NS A)  Type  1 
Programmable  In-Line  Encryption  Device  (PIED),  (p.  9) 

According  to  Director,  Capabilities  Development  Directorate  Letter  of 
Clarification  (LOC;  2012),  the  “established  JBC-P  FoS  Authorized  Acquisition  Objective 
(AAO)  is  26,566  systems  (Handheld:  6,920,  Mounted:  18,275,  TOC  Kit:  1,371)”  (p.  1). 
The  PMO  fielding  strategy  for  the  JBC-P  capabilities  is  aligned  with  the  Army’s.  If  the 
schedule  holds,  both  Services  will  request  a  fielding  decision  in  1st  quarter  FY2014  after 
a  successful  operational  test.  According  to  the  JBC-P  CDD  (Department  of  the  Army, 
2008),  “initial  operational  capability  (IOC)  is  achieved  when  one  Marine  Corps  Regiment 
is  completely  fielded  with  all  variations  of  the  JBC-P  Product  Line”  (p.  65).  The  IOC  is 
tentatively  scheduled  for  4th  quarter  FY2014.  Figure  10  depicts  the  JBC-P  FoS  schedule. 

Moreover,  JBC-P  FoS  is  currently  supported  by  separate  funding  lines  for  the 
individual  increments.  Late  in  FY2012,  the  PMO  initiated  a  two-year  transition  strategy 
to  merge  acquisition  efforts  along  with  funding  lines  in  order  to  support  planned  FY2014 
Increment  II  fielding. 
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Figure  10.  JBC-P  FoS  Major  Events  Schedule  (From  Product  Manager,  DFSA,  2012) 


JCR  version  1.3  is  the  baseline  for  the  JBC-P  software  to  reduce  the  development 
risk  associated  with  software  development.  JBC-P  enhances  both  FBCB2  and  DACT 
capabilities  and  leverages  mature  technologies  that  have  been  combat  proven  by  both  the 
Marine  Corps  and  Army.  PM  FBCB2  established  an  MOA  with  the  government  software 
development  agency,  Aviation  and  Missile  Research,  Development  and  Engineering 
Center  (AMRDEC)  Software  Engineering  Directorate  (SED),  in  Huntsville,  AL,  to 
develop  and  integrate  the  JBC-P  capabilities  (Program  Manager  Force  XXI  Battle 
Command  Brigade  and  Below,  PEO  C3T,  2009,  p.  20).  The  enhanced  capabilities  will 
leverage  the  current  JCR  NOC  and  existing  network  architecture.  The  JBC-P  TEMP 
provides  more  clarity  on  the  upgrade. 

JBC-P  builds  on  the  experience  of  over  thirteen  years  of  evolutionary 
development  of  digital,  battle  command  information  systems  that  provides 
integrated,  on-the-move,  timely,  relevant  Command  and  Control/ 
situational  awareness  (C2/SA)  information  to  tactical  combat,  combat 
support  and  combat  service  support  commanders,  leaders,  and  key  C2 
nodes.  The  first  increment  (FBCB2)  concentrated  on  the  capabilities 
required  to  prosecute  the  close  fight  and  was  primarily  focused  on  the 
Anny  units  at  the  Brigade  and  Below.  The  second  increment,  the  JBC-P 
program,  will  become  the  cornerstone  of  the  Joint  Blue  Force  Situational 
Awareness  (JBFSA)  envisioned  to  support  the  joint  warfighter.  The  JBC-P 
program  will  be  an  evolutionary  acquisition  delivering  JBC-P  software, 
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leveraging  on  existing  assets  and  new  hardware  capabilities.  Future  JBC-P 
hardware  procurements  will  be  directly  linked  to  the  JBC-P  software 
development  efforts  as  a  baseline  requirement.  Subsequent  future 
contracts  for  JBC-P  hardware  will  be  obtained  with  full  and  open 
competition  with  a  requirement  to  perform  with  the  JBC-P  software,  (p. 

20) 

2.  Capabilities 

This  section  was  extracted  from  the  JROC  validated  and  approved  JBC-P  CDD, 
dated  May  6,  2008  (Department  of  the  Anny,  2008).  The  document  is  a  conversion  from 
the  Anny  FBCB2  ORD  and  Marine  Corps  DACT  ORD,  to  a  JBC-P  CDD  (Department  of 
the  Anny,  2008,  p.  20).  The  JBC-P  CDD  also  states  the  basis  for  JBC-P  as  “the  Joint 
Requirements  Oversight  Council  Memorandums  161-03  and  163-04  directive  to 
converge  to  a  single  JBFSA  capability  for  the  Army  and  Marine  Corps”  (Department  of 
the  Army,  2008,  p.  2).  Additionally,  the  document  takes  into  consideration  and  leverages 
a  number  of  fielded  systems  and  others  still  in  development. 

The  JBC-P  capabilities  include  the  following: 

•  provides  an  enhanced  situational  awareness  of  the  environment  as  well  as 
enhanced  collaborative  decision-making  processes, 

•  allows  joint  forces  to  exploit  network  linkages  among  dispersed  joint 
forces  to  improve  coordinated  maneuver  and  integrated  situational 
awareness, 

•  allows  the  future  joint  forces  to  be  able  to  share  and  exchange  information, 

•  supports  a  system  that  is  deployable  worldwide,  and 

•  supports  all  types  of  units  and  operations.  Additionally,  the  system  allows 
for  the  joint  force  to  rapidly  shift  from  one  operation  to  another  with  little 
to  no  interruption.  (Department  of  the  Anny,  2008,  p.  9) 

Moreover,  the  CDD  describes  the  JBC-P  strategy  as  the  following: 

The  overall  JBC-P  strategy  is  to  provide  incremental  capabilities  to  the 
joint  force  that  support  current  and  future  joint  operational  concepts. 

Based  on  funding,  technical  feasibility,  performance  and/or  schedule 
issues,  particular  JBC-P  increments  may  only  provide  partial  capability. 

We  will  develop  future  increments  as  the  joint  warfighters  increase 
their  understanding  of  already  developed  capabilities  and  required 
Transformational  technologies  continue  to  mature.  (Department  of  the 
Army,  2008,  p.  14) 
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d.  Key  Performance  Parameters 

The  following  JBC-P  CDD  (Department  of  the  Army,  2008)  excerpts 
provide  details  on  the  system’s  key  performance  parameters  (KPP)  along  with  each 
corresponding  threshold  and  objective  measure. 

KPP  1 .  Net  Ready. 

JBC-P  must  support  Net-Centric  military  operations.  JBC-P  must  be  able 
to  enter  and  be  managed  in  the  network,  and  exchange  data  in  a  secure 
manner  to  enhance  mission  effectiveness.  JBC-P  must  continuously 
provide  survivable,  interoperable,  secure,  and  operationally  effective 
information  exchanges  to  enable  a  Net-Centric  military  capability. 

(a)  Threshold.  JBC-P  must  fully  support  execution  of  joint  critical 
operational  activities  identified  in  the  applicable  joint  and  system 
integrated  architectures  and  the  system  must  satisfy  the  technical 
requirements  for  transition  to  Net-Centric  military  operations. 

(b)  Objective.  JBC-P  must  fully  support  execution  of  all  operational 
activities  identified  in  the  applicable  joint  and  system  integrated 
architectures  and  the  system  must  satisfy  the  technical  requirements  for 
Net-Centric  military  operations.  (Department  of  the  Army,  2008,  p.  15) 

KPP  2.  Shared  Blue  Situational  Awareness. 

(a)  Threshold.  All  Operational  JBC-P  equipped  platforms  must  display,  as 
reported  by  other  JBC-P  FoS,  75%  of  joint  PLI  within  the  platform 
immediate  battlespace  and  65%  within  the  platform  extended  battlespace. 

The  friendly  location  data  will  be  accurate  to  within  200  meters  for  ground 
platforms,  50  meters  for  dismounted  soldiers,  500  meters  for  rotary  wing 
or  UAV  aircraft  of  the  actual  position.  For  relatively  stationary  platforms 
the  PLI  data  will  be  reported  within  20  minutes  for  ground  mounted  and 
dismounted  platforms  and  2  minutes  for  aviation  platforms. 

(b)  Objective.  All  Operational  JBC-P  shall  display,  as  reported  by  other 
JBC-P  FoS,  95%  of  joint  PLI  w/in  immediate  battlespace  and  85%  w/in 
extended  battlespace.  The  friendly  location  data  will  be  accurate  to  within 
100  meters  platform,  10  meters  dismounted  soldier,  250  meters  rotary 
wing/UAV  aircraft  of  the  actual  position.  (Department  of  the  Army,  2008, 

p.  16) 

KPP  3.  Shared  Survivability 


(a)  Threshold.  Survivability  infonnation,  as  reported  by  JBC-P  FoS,  must 
be  displayed  and  an  alert  provided  on  75%  of  operational  JBC-P  equipped 
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platforms  within  the  applicable  danger  zone  within  the  specified  time  of 
the  entity  being  reported. 

(b)  Objective.  Survivability  information,  as  reported  by  JBC-P  FoS,  must 
be  displayed  and  an  alert  provided  on  95%  of  operational  JBC-P  equipped 
platforms  within  the  applicable  danger  zone  within  the  specified  time  of 
the  entity  being  reported.  (Department  of  the  Army,  2008,  p.  16) 

KPP  4.  Sustainment  (Materiel  Availability). 

(a)  Threshold.  The  operational  availability  for  the  JBC-P  shall  be  90%. 

(b)  Objective.  95%.  (Department  of  the  Anny,  2008,  p.  16) 

e.  Handheld 

The  handheld  solution  is  no  longer  under  the  JBC-P  development  effort. 
The  requirement  has  transitioned  to  the  Nett  Warrior  dismounted  effort.  The  Nett  Warrior 
CDD  requirements  were  mapped  against  the  JBC-P  CDD  and  a  determination  was  made 
that  they  were  similar  enough  that  Nett  Warrior  would  take  responsibility.  However,  the 
Marine  Corps  still  relies  on  the  JBC-P  CDD  for  its  solution,  particularly  for  testing.  The 
JBC-P  FoS  PMO  established  a  workgroup  to  determine  what  specific  Marine  Corps 
interoperability  requirements  are  met  in  the  Nett  Warrior  CDD.  The  workgroup  results 
are  still  pending.  Furthermore,  the  PMO  is  uncertain  the  solution  will  be  ready  for  the 
planned  IOT&E  during  NIE  13.2. 

3.  Software  Builds 

Part  of  the  Army’s  modernization  strategy  is  to  develop,  test,  and  field  associated 
capabilities  collectively  to  the  warfighter.  Capability  sets  are  inceptions  of  this  strategy. 
The  JROC-approved  JBC-P  CDD  operational  requirements  were  prioritized  to  be 
developed  accordingly  via  software  builds.  The  software  builds  are  incorporated  within 
pooled  capability  sets  (CS)  and  evaluated  for  fielding  during  the  NIE.  Subsequent 
software  builds  on  the  previous  software.  JBCP  is  being  developed  incrementally,  and 
this  approach  supports  the  program  strategy.  A  combined  team  that  included 
representatives  from  the  Marine  Corps,  Army,  Special  Operations  Forces,  and  other 
stakeholders  completed  the  prioritized  list  of  requirements.  The  team  conducted  a  System 
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Requirements  Review  (SRR)  semi-annually  to  review  the  prioritized  list.  During  the 
SRR,  the  team  recommended  changes  to  existing  requirements  or  introduces  new  ones. 

There  are  specific  artifacts  that  are  associated  with  introducing  capabilities  into 
JBCP  software  builds  in  which  the  Marine  Corps  have  been  participating  in.  The  platform 
software  is  the  same  for  the  Marine  Corps  and  Army.  However,  the  Marine  Corps  team 
has  been  developing  its  own  capabilities  packages  for  the  builds.  These  capabilities  are 
specific  to  Marine  Corps  higher  echelon  requirements.  Currently,  JBC-P  has  four 
software  builds  that  comprise  the  core  system  requirements.  These  initial  software  builds 
contain  the  bulk  of  the  Army  requirements  and  the  Marine  Corps’  interoperability 
requirements.  Software  Build  Four  contains  the  capability  to  interface  with  JTCW.  It 
includes  the  ability  to  share  VMF  with  JTCW  and  to  send  PLI  reports  to  JTCW.  Software 
Build  Four  is  a  deliverable  for  CS  13.  The  following  provides  the  Army  clarification  for 
CS  13. 

CS  13  will  begin  to  field  to  eight  brigade  combat  teams  in  2012.  CS  13  is 
the  first  fully-integrated  suite  of  network  components  fielded  as  part  of 
Capability  Set  Management  and  as  a  result  of  the  Army’s  new  Agile 
Process.  CS  13  delivers  an  unprecedented  integrated  network  solution 
capable  of  supporting  mission  command  requirements  for  the  full  range  of 
Army  operations,  and  an  integrated  voice  and  data  capability  throughout 
the  entire  BCT  formation.  (Department  of  the  Army,  n.d.a) 

Software  Build  Five  is  projected  to  include  additional  Marine  Corps  capabilities 
required  for  JBC-P  initial  fielding.  The  build  includes  the  ability  to  build  overlays,  pull 
unit  and  platform  tracks  along  with  PLI  from  JTCW,  and  push  out  to  selected  JBC-P 
users.  Moreover,  Build  Five  contains  enhanced  JTCW  interoperability  and  initial 
interoperability  capability  with  other  Marine  Corps-unique  systems  and  tactical  radio 
wave  forms. 

4.  Test  and  Evaluation 
a.  Overview 

The  Marine  Corps  test  strategy  is  aligned  to  the  Army.  Both  Services 

evaluate  JBC-P  capabilities  utilizing  the  JBC-P  CDD  KPPs.  Joint  test  events  are 

conducted  to  maximize  resources  and  better  assess  mutual  requirements.  When 

41 


necessary,  the  Marine  Corps  team  conducts  independent  testing  for  specific  Marine  Corps 
requirements.  In  addition  to  the  established  test  sites  at  SPAWAR  and  MCTSSA,  the 
JBC-P  FoS  PMO  provided  test  personnel  to  augment  the  Army’s  test  team  collocated  at 
the  SED.  This  initial  team’s  primary  mission  is  to  conduct  SSAT,  in  order  to  test  Marine 
Corps-specific  requirements  in  each  build  released  by  the  developer.  These  three  sites  are 
mutually  supported  with  dedicated  personnel  to  assess  each  JBC-P  software  build.  The 
comprehensive  teams  at  the  SPAWAR  and  MCTSSA  are  tasked  with  conducting  all 
Increment  I  and  Increment  II  development  testing  efforts. 

b.  Test  and  Evaluation  Master  Plan 

The  JBC-P  Test  and  Evaluation  Master  Plan  (TEMP)  (U.S.,  Army  Office 
of  Program,  FBCB2,  2011)  underwent  a  vigorous  review  and  edit  process  by  the 
stakeholders.  The  finalized  version  is  enroute  to  approval.  The  following  provides  more 
details  on  the  document. 

The  TEMP  describes  an  integrated  test  and  evaluation  strategy  that  will 
leverage  all  available  data  sources  including  but  not  limited  to  plan 
developmental  and  operational  testing.  The  TEMP  also  includes  measures 
to  evaluate  the  perfonnance  of  the  system  during  these  test  periods;  an 
integrated  test  schedule;  and  the  resource  requirements  to  accomplish  the 
planned  testing.  (U.S.  Army  Office  of  Program  Office,  FBCB2,  2011, 

p.  1-1) 

The  following  describes  the  JBC-P  Test  and  Evaluation  Working  Integrated 
Product  Team  (T&E  WIPT)  that  was  established  to  be  the  focal  point  to  manage  testing. 

T&E  WIPT  membership  will  include  all  organizations  having  direct  or 
indirect  testing  responsibilities.  These  organizations  include:  PM  FBCB2, 
MARCORSYSCOM,  Army  Test  and  Evaluation  Command  (ATEC),  PM 
Heavy  Brigade  Combat  Team  (HBCT),  MCTSSA,  SED,  Central 
Technical  Support  Facility  (CTSF)  and  the  Joint  Interoperability  Test 
Center  (JITC).  The  JBC-P  system  T&E  concept  includes  test  events 
conducted  by  both  the  contractor  and  the  Government  to  ensure  that  the 
JBC-P  software  and  hardware  variants  meet  performance  requirements, 
are  safe  for  use  by  soldiers,  are  operationally  suitable,  survivable  and 
effective,  interoperable,  and  qualified  for  use.  (U.S.  Army  Office  of 
Program  Office,  FBCB2,  201 1.  p.  3-1) 
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c.  Development  Tests 

As  a  result  of  lessons  learned  from  JCR  testing,  all  JBC-P  DT  events  are 
jointly  coordinated.  The  PEO  C3T  ADM  (Department  of  the  Army,  PEO  C3T,  2012) 
requires  the  PMO  to  “conduct  a  fonnal  DT  and  LUT  to  confirm  the  system’s  readiness  to 
conduct  Initial  Operational  Test  and  Evaluation  (IOT&E)”  (p.  1).  Moreover,  the  ADM 
states  that  the  PMO  must  “return  to  the  MDA  post  LUT  and  provide  an  update.  MDA 
must  be  confident  of  system  maturity  and  ability  to  meet  criteria  to  enter  IOT&E,  else 
approval  will  be  rescinded”  (Department  of  the  Army,  PEO  C3T,  2012,  p.  1).  Each 
software  build  released  by  the  developers  undergoes  the  same  series  of  test  events  as 
JCR,  SSAT,  RRE,  JITC  Certification,  Risk  Assessment,  and  FUE/LUT/NIE.  The 
SPAWAR  Software  Test  Report  (SPAWAR,  Atlantic,  2012b)  states  the  major  difference 
between  the  RREs  for  JCR  and  JBC-P  is  that  the  JBC-P  “event  architecture  not  only 
provides  the  connectivity  to  exercise  VMF  messaging,  PLI,  and  interoperability,  but  also 
backwards  compatibility  with  JCR”  (p.  2).  Additionally,  joint  User  Juries  were  conducted 
during  the  early  stages  of  development  to  solicit  feedback  from  fleet  Marines  and 
soldiers.  The  users  evaluated  handheld  prototypes  and  the  mounted  software  and  then 
completed  surveys  at  the  conclusion  of  each  event.  The  feedback  drove  the  development 
effort  for  the  new  user  interface  that  is  similar  to  today’s  gaming  interface. 
Representatives  from  the  TICM,  CD&I,  SED,  JBC-P  FoS  PMO,  and  PM  FBCB2 
executed  and  monitored  each  event. 

(1)  Results.  The  Marine  Corps  Test  Team  was  not  actively 
engaged  in  testing  of  the  first  three  software  builds.  The  builds  did  not  address  Marine 
Corps  requirements,  so  the  team’s  role  was  limited.  Software  Build  Four  was  the  first  to 
complete  the  full  gamut  of  test  events  by  both  Services.  RRE- 11  was  completed 
September  10,  2012.  Overall,  the  test  was  a  success.  The  test  team  identified  numerous 
issues  with  the  software  build.  The  SPAWAR  Software  Test  Report  for  the  JBC-P  RRE- 
11  Test  Event  (SPAWAR,  Atlantic,  2012b)  states  that  the  priority  issues  were  “incorrect 
Marine  Corps  symbol  code  information  displayed  on  the  JTCW,  [the]  data  set  (UTO) 
used  by  JBC-P  was  unique  and  not  compatible  with  JCR  (different  formats),  and  field 
orders  sent  from  JBC-P  were  unable  to  send  attached  overlays  that  contained  free  draw 
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objects”  (p.  5).  The  priority  issues  were  resolved  after  coordinating  with  the  Army  team. 
The  fixes  were  promptly  “integrated  and  distributed  to  all  test  sites  to  improve  software 
stability”  (SPAWAR,  Atlantic,  2012b,  p.  6).  At  the  event  conclusion,  the  test  team 
recommended  to  “refine  and  publish  USMC  data  initialization  processes  for  inclusion  of 
USMC  JBC-P  roles  in  the  test  build  [and]  ...  USMC  data  initialization  processes  for  JCR 
test  UTO  distribution  and  loading  of  data  into  C2R”  (SPAWAR,  Atlantic,  2012b,  p.  7). 

In  November  2012,  the  Marine  Corps  conducted  an  FUE  in 
conjunction  with  NIE  13.1.  The  FUE  was  successful  in  evaluating  JTCW  interoperability 
utilizing  static  MCTSSA  JBC-P  platforms.  The  FUE  test  report  is  being  incorporated 
with  the  Anny’s  NIE  13.1  report  and  is  not  yet  finalized. 

d.  Operational  Testing 

PEO  C3T  ADM  (Department  of  the  Army,  PEO  C3T,  2012)  “authorized 
entry  into  the  Low  Rate  Initial  Production  (LRIP)  phase  for  the  purpose  of  completing 
manufacturing  development  and  conducting  IOT&E.”  NIE  13.2,  scheduled  to  begin 
March  2013,  will  be  the  IOT&E  event.  For  both  Services,  Software  Build  Five  will 
support  the  scheduled  IOT&E.  The  JBC-P  FoS  PMO  is  awaiting  delivery  of  the  software 
build  to  schedule  the  required  SSAT  and  RRE.  The  JBC-P  TEMP  (U.S.  Army  Office  of 
the  Program  Office,  2011)  states  that  the  IOT&E  objectives  are  to  “ensure  the  ability  of 
the  JBC-P  to  be  integrated  on  a  variety  of  system  platforms  without  inhibiting  soldier 
performance,  seamlessly  interoperate  with  Battle  Command  Systems,  and  evaluate  JBC- 
P’s  operational  effectiveness,  suitability,  and  survivability”  (p.  3-4).  The  draft  TEMP 
also  describes  each  Service  DOT&E  activity’s  responsibility  for  operational  testing.  It 
designates  ATEC  as  the  lead  OT  agency  (lead  evaluator)  and  MCOTEA  as  supporting 
agency.  The  following  TEMP  excerpt  provides  details  on  each  activity’s  responsibility: 

ATEC  is  responsible  for  planning  and  conducting  developmental  and 
operational  testing  and  completing  independent  system  evaluations  of  the 
JBC-P  systems.  Both  the  Developmental  Test  Command  (DTC)  and 
Operational  Test  Command  (OTC)  develop  test  plans  and  instrumentation 
to  support  testing,  as  well  as  conduct  test  events. . . 
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Marine  Corps  Operational  Test  and  Evaluation  Activity  (MCOTEA) 
independently  plans,  executes  and  evaluates  testing  of  material  solutions 
against  Warfighter  capabilities,  under  prescribed  realistic  conditions  and 
doctrine,  to  determine  operational  effectiveness  and  suitability.  MCOTEA 
is  the  authority  for  Operational  Test  and  Evaluation  for  the  USMC  and 
will  plan  and  execute  USMC-specific  OT&E.  MCOTEA  will  support 
ATEC  for  Joint  Interoperability  T&E  planning  and  reporting.  (U.S.  Army 
Office  of  Program  Office,  FBCB2,  201 1,  p.  2-2) 

To  effectively  simulate  the  realistic  operational  environment,  the  agencies  are 
coordinating  to  attach  the  Marine  Corps  unit  to  the  OTC  unit  at  Fort  Bliss.  A  truly  joint 
evaluation  that  includes  an  assortment  of  Marines  and  Soldiers  from  one  location  has 
always  been  a  goal  on  this  effort  and  also  DOT&E  encouraged. 

C.  SUMMARY 

This  chapter  provided  the  reader  with  details  on  the  incremental  approach  effort  to 
reach  SA  convergence.  It  also  described  each  increment’s  capabilities,  test  and  evaluation 
efforts  and  results  of  each  test  effort. 
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IV.  CONSIDERATIONS 


This  chapter  will  provide  some  key  considerations  from  the  analysis  of  Increment 
I  and  Increment  II.  It  will  describe  some  Anny  unique  resources  that  impact  how  the 
Marine  Corps  will  implement  the  increments. 

Joint  Capabilities  Release  (JCR)  and  Joint  Battle  Command-Platform  (JBC-P) 
were  intended  to  address  the  Joint  Requirements  Oversight  Council  (JROC)  directive  for 
a  joint  blue  force  tracking  capability  for  the  ground  forces.  However,  both  software 
solutions  are  more  Army  centric  than  Marine  Corps  centric.  As  a  result,  mismatches  exist 
within  and  beyond  the  JBC-P  between  the  Army  and  the  Marine  Corps.  The  primary 
challenge  for  the  Marine  Corps’  team  is  marrying  JBC-P  with  organic  Marine  Air- 
Ground  Task  Force  (MAGTF)  systems.  Additionally,  the  Marine  Corps  shares  the  current 
theater  of  operations  with  the  Army.  The  L-band  satellite  infrastructure  is  fully  supported 
with  Army  resources.  The  Marine  Corps  will  be  challenged  when  operating 
independently.  Moreover,  the  JBC-P  development  schedule  has  shifted  and  many  of  the 
Marine  Corps  capabilities  are  prioritized  lower  than  the  Army’s.  Consequently,  the 
Marine  Corps  schedule  may  be  disjointed  from  the  Army’s  fielding  strategy. 

A.  SYSTEM  DEPENDENCIES 

JROC  Memorandum  163-04  (JROC,  2004)  required  the  Army  and  the  Marine 
Corps  to  adopt  the  same  C2SA  systems  for  their  entire  hierarchy.  The  memorandum 
directed  the  Army  to  adapt  the  Joint  Tactical  Common  Operating  Picture  (COP) 
Workstation  (JTCW)  for  the  brigade  and  above  solution  and  the  Marine  Corps  to  adapt 
FBCB2  for  its  platforms  (battalion  and  below;  JROC,  2004).  However,  the  Army  moved 
away  from  that  path  and  designed  JCR  and  JBC-P  for  the  higher  echelon  solution,  using 
the  Anny  Battle  Command  System  (ABCS)  instead  of  JTCW.  The  Marine  Corps  requires 
JTCW  to  synchronize  all  the  systems  within  the  MAGTF  architecture.  JCR  and  JBC-P 
are  essentially  designed  towards  external  resources  that  reside  within  the  ABCS  and 
operate  as  a  system  of  systems.  Those  external  resources  are  dependent  on  the  system 
that  the  Marine  Corps  must  accommodate.  Marine  Corps  CONOPS  was  tailored  to 


47 


function  within  the  current  technical  parameters  versus  supporting  tactical  networks  in 
order  to  make  JCR  and  JBC-P  operationally  effective  for  Marine  Corps  units.  The 
dependencies  further  complicate  the  already  tangled  architecture  and  increase  the  chance 
for  potential  network  disruption.  This  issue  exists  in  Increment  I  and  has  not  been 
completely  resolved  for  Increment  II. 

B.  COMMAND  AND  CONTROL  REGISTRY 

The  Marine  Corps  does  not  have  a  high  tier  address  book  concept  for  all  its  units 
that  is  similar  to  the  Command  and  Control  Registry  (C2R).  Data  products  such  as  unit 
reference  numbers  (URN),  organization  structure,  and  Internet  protocol  (IP)  addresses 
must  be  loaded  to  C2R  in  order  to  operate  on  the  network.  The  Army  established  Project 
Director  Tactical  Network  Initialization  (PDTNI)  to  manage  all  data  products  for  ABCS. 
The  PDTNI  collects  and  manages  all  data  products  to  enable  digital  communication  and 
interoperability  across  its  tactical  Internet  (peoc3t.army.mil/tni).  In  the  Marine  Corps, 
individual  units  are  responsible  to  configure  their  IP  addresses.  They  assign  their  unit 
names  to  be  used  and  create  the  IP  structure  for  the  organization.  The  Marine  Corps’ 
expeditionary  nature  and  consequent  constant  changing  of  IPs  and  network  structure  do 
not  support  the  C2R  concept. 

C.  UNIVERSAL  COLLABORATION  BRIDGE 

There  is  a  distributed  chat  capability  that  is  associated  with  JBC-P.  Within  the 
ABCS,  the  Universal  Collaboration  Bridge  (UCB)  program  provides  a  translation  service 
to  JBC-P.  UCB  translates  one  chat  protocol  to  another  for  the  ABCS  system-of-systems 
concept.  The  Marine  Corps  has  no  equivalent  service.  The  Marine  Corps  team  is  working 
on  a  solution  in  order  to  transmit  JTCW-generated  messages  to  JBC-P. 

D.  DATA  DISTRIBUTION  SYSTEM 

Service  interoperability  is  dependent  on  the  Data  Distribution  System  (DDS), 
Global  Command  and  Control  System-Army  (GCCS-A),  and  the  Army  Service 
Component  Command  (Army  cell)  collocated  with  the  regional  COCOM.  The 
procedures  to  enable  data  flow  to  the  joint  community,  via  both  JCR  and  JBC-P,  have  not 
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been  solidified  as  yet.  The  connection  has  been  sporadic  during  DT  for  a  number  of 
different  reasons.  The  Marine  Corps  team  does  not  have  a  high  degree  of  confidence  the 
transmissions  to  the  joint  community  will  be  seamless  in  operational  environments. 
Situational  awareness  reliability  during  prior  test  events  provided  an  indicator  of  a 
complicated  configuration  that  is  difficult  to  maintain.  Additionally,  a  major  challenge 
yet  to  be  executed  is  establishing  a  connection  from  a  Marine  Expeditionary  Unit, 
embarked  on  a  naval  vessel,  to  a  regional  COCOM. 

E.  SATELLITE  COVERAGE 

BFT  satellite  coverage  is  not  global,  and  with  the  current  fiscal  environment, 
global  coverage  once  JCR  and  JBC-P  are  fielded  may  not  be  achievable.  The  Marine 
Corps  has  been  sharing  the  battlespace  with  Army  units  executing  combat  operations  in 
support  of  the  Global  War  on  Terrorism.  Thus  far,  the  Army  has  been  financing  the 
limited  Marine  Corps’  L-band  bandwidth  usage.  However,  today’s  BFT  satellite  coverage 
area  does  not  support  expeditionary  operations.  Once  JCR  and  JBC-P  is  widely  fielded 
throughout  the  Marine  Corps  operating  force  and,  specifically,  the  Marine  Expeditionary 
Units,  the  Marine  Corps  will  have  to  support  its  satellite  usage.  Currently,  the  Army 
provides  BFT  coverage  only  for  regions  where  BFT-equipped  Army  units  are  located. 
The  Defense  Information  Systems  Agency  (DISA),  in  the  near  future,  will  be  responsible 
for  managing  all  L-band  satellite  contracts  for  the  DoD.  The  JBC-P  FoS  PMO  is 
anticipating  a  request  for  funding  from  DISA  in  the  near  future  to  support  a  wider 
satellite  coverage  area.  Revealed  during  discussions  with  PMO  leadership,  this  issue  is  a 
top  primary  and  has  been  briefed  to  Headquarters  Marine  Corps  Command,  Control, 
Communications,  Computers,  and  Intelligence  for  resolution. 

F.  SCHEDULE  SHIFT 

The  incremental  improvement  approach  for  JBC-P  software  development  has 
been  a  challenge  for  the  developer.  Each  proceeding  software  build  contains  more 
capabilities  than  the  previous  version.  The  initial  coupled  capabilities  priority  list  has 
changed  and  some  Marine  Corps-specific  requirements  were  lowered.  Furthermore,  no 
developmental  plan  currently  exists  for  some  of  the  lowered  priority  requirements,  and 
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the  developer  has  struggled  to  achieve  the  threshold  capabilities  in  Build  Four.  Early  test 
results  show  limitations  exist  with  the  variable  message  fonnat  (VMF)  standard,  which  is 
a  significant  requirement  for  JTCW.  The  originally  planned  capabilities  in  Build  Five  are 
the  first  Marine  Corps  fieldable  version  of  the  JBC-P  software.  The  PMO  is  not  confident 
follow-on  Software  Build  Five  will  contain  improved  VMF  capabilities.  Additionally,  the 
Marine  Corps  expected  an  improved  JTCW  interface  in  Build  Five  to  go  beyond  the 
threshold  interoperability  capabilities.  The  expected  capabilities  include:  Improved  tracks 
and  overlays  exchanges,  automated  updates  to  the  operational  picture  in  JTCW,  and 
JTCW  data  exchanges  with  JBC-P.  Additionally,  the  PMO  anticipated  improvements  in 
the  functional  address  book  process  that  facilitates  address  book  information  interactions 
between  the  Army  and  the  Marine  Corps  systems. 

Moreover,  the  current  constrained  budgetary  environment  negatively  impacted 
JBC-P  funding.  The  development  effort  changed  to  accommodate  the  reduced  resources. 
The  PMO  is  not  confident  the  final  build  will  remain  on  schedule  and  anticipates 
significant  shifts  in  the  Software  Build  Five  release  schedule.  The  constraints  have 
reduced  the  Marine  Corps’  upcoming  future  years’  budgetary  controls.  Supporting 
Increment  I-equipped  units  in  OEF  is  priority.  Therefore,  procuring  the  hardware 
upgrades  associated  with  Increment  II  in  a  timely  manner  will  be  a  challenge. 

G.  SUMMARY 

This  chapter  provided  key  considerations  that  hamper  Marine  Corps 
implementation  of  the  JCR  and  JBC-P  packages. 
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V.  CONCLUSION 


This  chapter  summarizes  what  was  learned  while  conducting  this  research.  The 
chapter  provides  recommendations  for  procedure  and  policy  that  will  lessen  the 
complexities  of  joint  programs.  Additionally,  this  chapter  provides  recommendations  for 
further  research  to  better  determine  Increment  II  feasibility  for  fielding  to  the  Marine 
Corps  and  analysis  of  Blue  Force  Tracker  use  in  Marine  Corps  expeditionary  operations 
other  than  war. 

A.  SYNOPSIS 

The  combination  of  the  lethality  of  modern-day  weaponry,  the  chaos  that  exists 
on  a  joint  battlefield,  human  factors,  and  stove-piped  tactical  situational 
awareness/command  and  control  systems  has  increased  the  potential  for  inadequate 
situational  awareness  and,  in  the  worst  case,  fratricide  occurrences.  The  Joint  Oversight 
Requirement  Committee’s  directive  (JROCM,  2004)  for  a  Joint  Blue  Force  Situational 
Awareness  capability  is  warranted  to  improve  tactical  situational  awareness  and  reduce 
fratricide  occurrences.  This  analysis  of  the  Marine  Corps’  efforts  toward  a  viable  solution 
evidenced  that  the  overarching  capability,  as  envisioned  by  the  JROC,  cannot  come  to 
fruition  in  the  near  future.  As  is  common  in  most  joint  efforts,  differences  exist  between 
the  Marine  Corps  and  Army,  primarily  in  regard  to  requirements  and  organic  resources. 
These  differences  inhibit  developmental  efforts  and  hinder  the  likelihood  of  fielding 
similar  and  interoperable  capabilities. 

The  Marine  Corps  executed  key  efforts  to  comply  with  the  JROC  convergence 
directive:  First,  the  vehicle -mounted  Data  Automated  Communications  Tenninal 
(DACT)  variant  was  distributed  to  operating  forces  on  a  limited  basis;  second,  fielding 
the  dismounted  DACT  was  cancelled;  and  third,  Marine  Corps  System  Command 
(MARCORSYSCOM)  rapidly  procured  the  Anny’s  Blue  Force  Tracker  (BFT)  systems 
and  subsequently  fielded  to  Marine  units  in  the  combat  zones  and  at  home  stations.  The 
MARCORSYSCOM  program  management  office  (PMO),  Joint  Battle  Command- 
Platform  Family  of  Systems  (JBC-P  FoS)  initiated  actions  to  align  Marine  Corps  efforts 
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with  the  Army’s  aggressive  incremental  strategy  to  develop  the  joint  capability.  PMO 
JBC-P  FoS  established  dual  Marine  Corps-specific  test  sites,  augmented  the  Army’s  test 
team  that  was  collocated  with  the  software  developers,  and  executed  concurrent  test 
events  to  synchronize  with  the  Army  test  schedule. 

The  convergence  effort  is  plagued  with  challenges.  Joint  Capability  Release 
(JCR)  represents  Increment  I  towards  interoperability,  but  its  software  and  hardware 
capabilities  have  not  proven  fully  capable  of  meeting  Marine  Corps  operational 
requirements.  JCR  is  essentially  designed  towards  the  Anny  Battle  Command  System 
(ABCS).  The  enhanced  capability  requires  an  overly  complex  architecture  that  is 
dependent  on  organic  ABCS  resources  that  do  not  reside  within  the  Marine  Air-Ground 
Task  Force  architecture.  This  dependency  was  evident  while  testing  JCR.  Testing 
revealed  an  overarching  lack  of  a  reliable  network  for  SA/C2  without  altering  Marine 
Corps  concept  of  operations.  Additionally,  reasonable  concerns  exist  in  developing, 
testing,  and  concept  of  employment  for  Increment  II,  Joint  Battle  Command-Platform 
(JBC-P).  JBC-P  is  being  developed  incrementally.  The  Services’  requirements  were 
prioritized,  coupled,  and  assigned  to  software  builds.  Each  subsequent  software  build 
adds  more  capabilities  to  the  previous.  The  software  build  development  schedule  shifted 
due  to  issues  with  the  developer,  which  resulted  in  many  Marine  Corps-specific 
requirements  being  lowered  on  the  priority  list.  Consequently,  the  planned  Marine  Corps 
fieldable  solution  is  now  delayed. 

Moreover,  the  Army  maintains  the  L-Band  satellite  network,  the  architecture  and 
resources  required  to  operate  the  BFT  system.  JCR  and  JBC-P  encompass  enhanced 
capability  to  the  current  network  and  architecture.  The  Army  provides  satellite  coverage 
for  all  regions  where  BFT-equipped  Army  units  are  located.  However,  the  resources  are 
limited  outside  those  regions  and  may  be  unavailable  for  Marine  forces  conducting 
traditional  expeditionary  missions. 

B.  LESSONS  LEARNED 

1.  JCR  represents  the  interim  solution  towards  full  convergence.  If  the 
Marine  Corps  had  greater  influence  during  the  JCR  developmental  phase,  most  of  the 
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challenges  would  have  been  mitigated.  JCR  and  subsequently,  JBC-P,  would  have  been 
designed  to  ultimately  support  the  current  Marine  Corps  architecture  and  concept  of 
operations  in  the  same  manner  as  the  Army.  Additionally,  greater  influence  during  the 
negotiation  sessions,  where  capability  priorities  were  being  established,  would  have 
ensured  a  practical  Marine  Corps  solution  and  facilitated  a  seamless  transition  to  JBC-P. 
The  Marine  Corps-specific  requirements  would  have  been  equivalently  considered  when 
establishing  the  capabilities  priority  list. 

2.  The  Marine  Corps  resources  are  limited,  but  available  resources  should 
have  been  directed  more  efficiently.  More  resources  should  have  been  dedicated  to 
expedite  responses  to  the  Army  workgroup’s  inquiries  on  Marine  Corps  capabilities.  As 
the  JCR  effort  winds  down,  more  JBC-P  FoS  PMO  assets  are  being  dedicated  to  JBC-P. 
The  purpose  is  to  develop  solutions  to  the  existing  architecture  and  capability  issues  that 
will  make  JBC-P  a  viable  solution  for  Marine  forces  with  reduced  consideration  for 
interoperability  with  the  Army. 

3.  The  JBC-P  FoS  PMO  should  have  more  effectively  communicated  the 
JCR  and  JBC-P  system  requirements  with  other  programs  within  the  MAGTF 
architecture.  There  are  several  Marine  Corps  programs  that  have  only  recently  been 
involved  in  evaluating  the  impact  of  fielding  JCR  and  JBC-P. 

C.  RECOMMENDATIONS 

1.  Procedural 

For  solutions  intended  for  multi-Service  purposes,  the  baseline  design  must 
support  all  Services’  resources.  Consistency  in  the  core  design  will  facilitate 
implementation  and  ultimately  enhance  suitability.  Program  funding  must  be  stabilized 
for  incorporating  all  of  the  joint  system  requirements,  not  just  the  funded  Service’s 
requirements.  This  is  even  more  relevant  during  the  foreseeable  stringent  budgetary 
environment,  which  dictates  a  heightened  emphasis  on  commonality  throughout  the 
Services.  Implementing  JROC-mandated  directives  between  the  Services  will  be  less 
challenging  if  solutions  are  designed  towards  an  impartial  Joint  Capabilities  Integration 
Development  System  process. 
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Moreover,  additional  consideration  must  be  given  to  the  fundamental  nature  in 
which  each  Service  fights,  while  simultaneously  maintaining  the  goal  of  Service 
interoperability.  To  be  a  tangible  force  multiplier,  the  capability  must  be  designed  to  fit 
within  the  Service’s  battlefield  concept  of  employment  and  facilitate  interoperability. 
Any  deviation  would  diminish  the  capability’s  value  to  the  warfighter  between  the 
Services.  Accomplishing  this  is  extremely  challenging  as  each  Service  must  maintain  the 
capability  to  operate  with  its  existing,  disparate  C2/SA  systems,  while  developing  future 
systems  that  are  interoperable. 

2.  Policy 

Long-standing  acquisition  and  funding  policies,  rooted  in  law,  remain  hindrances 
in  developing  truly  joint  systems.  Acquisition  funding  primarily  flows  through  each 
Service,  which  then  prioritizes  funding  toward  its  own  requirements,  often  at  the  expense 
of  a  less  well-funded  sister  Service.  While  Congress  is  able  to  “fence”  funding  for 
programs  through  specific  language  in  the  annual  appropriations  bill,  it  would  be  difficult 
to  address  the  specific  requirements  within  the  fenced  program.  This  would  continue  to 
allow  the  funded  Service  to  prioritize  the  Service-specific  requirements  and  ignore  the 
joint  or  sister  Service  requirements.  This  would  result  in  the  continued  development  of 
Service-specific  C2/SA  systems  that  are  not  particularly  interoperable  in  the  joint 
environment.  In  turn,  future  C2/SA  developments  would  be  constrained  by  the  Service- 
specific  system  that  was  fielded  and  the  issue  would  propagate  infinitely. 

While  the  Joint  Chiefs  of  Staff  have  influence  on  the  acquisition  process  through 
the  JROC,  there  is  little  that  can  be  done  when  funding  to  develop  a  Service’s  specific 
requirement  is  not  available.  Joint  PMO’s  that  report  directly  to  the  Defense  Acquisition 
Executive  (DAE)  have  been  established  to  help  eliminate  the  problem  with  Service 
acquisition  funding,  and  that  may  be  one  tactic  that  could  be  employed  to  keep  the  focus 
on  the  joint  requirements. 
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3. 


For  Further  Research 


Marine  Corps’  JBC-P  Fielding  Strategy  After  Network  Integration 
Evaluation  13.2  and  Other  Follow-On  Evaluations 

This  analysis  is  insufficient  to  determine  the  feasibility  of  the  Joint  Battle 
Command-Platform  (JBC-P)  capabilities  within  the  Marine  Corps  and  realizing  the  Joint 
Requirements  Oversight  Council  vision  for  full  Blue  Force  Situational  Awareness 
convergence.  Better  determination  of  the  operational  effectiveness  and  suitability  of  JBC- 
P,  within  the  Marine  Air-Ground  Task  Force  architecture,  will  be  made  by  analyzing  the 
initial  operational  test  and  evaluation  test  report  from  Network  Integration  Evaluation 
13.2  (March  to  May  2013). 

Analyze  BFT  Use  During  Marine  Corps  Expeditionary  Operations  Other 
Than  War 

Findings  from  this  analysis  may  provide  a  realistic  view  of  the  complexity  of  joint 
systems  while  meeting  Service-specific  requirements.  Additionally,  the  findings  may 
help  detennine  specific  Marine  Corps  capabilities  that  should  be  included  in  future  JBC-P 
versions  to  support  traditional  expeditionary  operations  other  than  war  (e.g.,  humanitarian 
assistance,  disaster  relief,  and  noncombatant  evacuations).  However,  the  Marine  Corps 
should  evaluate  BFT  usage  in  areas  independent  of  Army  resources  to  better  determine 
suitability  and  reliability  of  the  satellite  network. 
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APPENDIX 


Sample  Risk  Reduction  Event  Test  Cases 
Attribute:  Maps 

Capability  Statements:  A  Key  Performance  Parameter  (KPP)  for  the  DACT 
consists  of  the  ability  to  display  a  map  with  GPS-derived  position  location 
information  (PLI)  [Interoperability  KPP]  represented  on  the  map. 

Measure:  %  Scalability. 

Measure:  %  Successful  Map  Retrieval. 

Measure:  %  Accurate  Display. 

Measure:  Storage  Capacity. 

Attribute:  Geodetic  Reference  and  Navigation 

Capability  Statements:  The  DACT  shall  provide  route  (straight  or  curved) 
distance  measuring,  coordinates  of  an  operator-designated  point  on  a  displayed 
map,  and  polar  coordinates  between  any  two  user-designated  points. 

Measure:  Distance  Calculation  Accuracy. 

Measure:  Route  Planning.  Pass 

Measure:  Direction  of  Travel  Accuracy.  Future  Test 

Measure:  Grid  Reference  Conversion  Accuracy. 

Attribute:  PLI 

Capability  Statements:  A  KPP  for  the  DACT  consists  of  the  ability  to  display  a 
map  with  GPS-derived  position  location  information  (PLI)  [Interoperability  KPP] 
represented  on  the  map. 

Measure:  Average  Time  for  Updates  (5  minutes  to  receive  updated  COP). 
Measure:  %  Completeness.  [Completeness  of  PLI  data  after  receipt  (via  terrestrial 
and/or  satellite  communications  medium)  from  adjacent  JBC-P  FoS  tenninals, 
JTCW  gateway,  FBCB2  NOC/FBCB2-BFT  L-Band  systems.] 

Measure:  Change  Track  View.  Not  a  DACT  ORD  Requirement 
Measure:  Display  Accuracy.  [Accuracy  of  PLI  displayed.] 

Attribute:  Overlays  and  Symbols 

Capability  Statements:  The  DACT  will  be  used  to  transmit,  receive,  store, 
retrieve,  create,  modify,  and  display  map  overlays  and  commanders’  critical 
information  requirements  (CCIRs). 

Measure:  MAGTF  Symbols  and  Unit  Identifiers  (Military  Standard  2525B). 
Measure:  Completeness.  [Overlay  completeness  after  transmission]. 

Measure:  Unit  Symbol  Scaling.  Not  a  DACT  ORD  Requirement 
Measure:  Overlay  Scaling. 

Measure:  %  Successful  Overlay  Creation. 

Measure:  Edit. 

Measure:  Display. 

Measure:  Select-ability. 
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Measure:  Transmit. 

Measure:  Receive. 

Measure:  Store. 

Measure:  Retrieve. 

Attribute:  Message  Handling 

Capability  Statements:  The  DACT  will  be  used  to  transmit,  receive,  store, 
retrieve,  create,  modify,  and  display  map  overlays  and  CCIR 
Measure:  Preformatted  Message  Template  Capability.  [23  message  formats 
according  to  the  DACT  ORD.  Nine  threshold  formats  at  a  minimum.] 

Measure:  Content  Completeness.  [Message  fonnats  contain  mandatory  fields.] 
Measure:  %  of  Distribution  Completeness.  [JBC-P  FoS  text  message  distribution 
capability  and  associated  message  log/delivery  status  tools.  Message  distribution 
to  all  designated  recipients  after  transmission.] 

Measure:  Accuracy.  [Accuracy  of  text  messages  after  distribution  to  designated 
recipients.] 

Measure:  Alerts.  [Audio  and  visual  message  alert  capability] 

Measure:  Sorting.  [Verily  message  sort  capability.] 

Measure:  %  Successful  Message  Creation. 

Measure:  Edit. 

Measure:  Display. 

Measure:  Transmit. 

Measure:  Receive. 

Measure:  Store. 

Measure:  Retrieve. 

Measure:  Attachments. 

Attribute:  Cryptographic  Capability 

Capability  Statements:  The  GPS  receiver  shall  provide  the  ability  to  utilize  an 
electronically  inserted  cryptographic  key. 

Measure:  Verify  GPS  Cryptographic  Capability. 

Attribute:  Rapid  Purge  Function 

Capability  Statement:  The  DACT  will  have  a  rapid  purge  function  for  critical 
operational  information  and  GPS  key  (if  installed)  to  guard  against  hostile 
exploitation. 

Measure:  Average  purge  time  (<  10  min). 

Measure:  Zeroize  GPS  Key. 

Measure:  Remote  Purge.  [JBC-P  FoS  ability  to  purge  hard  drive  and  GPS  key 
from  a  remote  location.] 

Attribute:  MAGTF  Command,  Control,  Communication,  and  Intelligence 
Network  Interoperability 

Capability  Statements:  The  mounted  DACT,  when  connected  to  a  local  network 
segment,  must  have  the  capability  to  connect  to  existing  network  printers  to  allow 
the  user  to  print  messages  (Threshold)  and  graphics  (Objective). 
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Measure:  Interoperability  with  JTCW. 

Measure:  Interoperability  with  transmission  medium  (EPLRS). 

Measure:  Positive  Indication  of  Connectivity  with  JTCW  Gateway. 

Attribute:  Joint  and  Allied/Coalition  C2  System  Interoperability 
Capability  Statement:  The  DACT  will  be  in  compliance  with  all  appropriate 
options  within  applicable  standards  categories  of  the  Department  of  Defense  Joint 
Technical  Architecture  (JTA)  to  include  infonnation  processing  standards, 
information  transfer  standards,  information  modeling  standards,  human-computer 
interface  standards,  and  information  systems  security  standards. 

Measure:  Net  Ready  KPP. 

Measure:  JITC  Certification 

Attribute:  Compatibility 

Capability  Statements:  The  DACT  shall  be  capable  of  sending  data  via  frequency 
hopping  radios  to  reduce  the  effects  of  electronic  warfare. 

Measure:  Compatible  with  Host  Platform.  Hardware 

Attribute:  Reliability 

Capability  Statements:  The  DACT  shall  have  a  threshold  mission  reliability  of 
90%  and  an  objective  mission  reliability  of  95%.  This  reliability  shall  include 
both  hardware  and  software. 

Measure:  Reliability  Growth  Plan. 

Measure:  Software  Metrics.  [Reliability  Metric — how  many  faults  in  the  software 
as  well  as  the  number  of  faults  expected  when  the  software  is  used  in  its  intended 
environment.] 

Attribute:  Self-Check  Capability 

Capability  Statements:  Upon  activating  the  DACT,  a  top-level  self-check  shall  be 
performed.  If  a  fault  is  detected,  the  DACT  shall  display  an  error  message 
indicating  the  fault. 

Measure:  Self-Check  Capability  Present. 

Measure:  Self-Check  Fault  Isolation  Accuracy  (>  90%). 

Measure:  Self-Check  False  Alarm  Rate  (<  10%). 

Attribute:  Impact  on  Related  Systems 

Capability  Statement:  Personnel  requirements  to  operate  and  maintain  the  DACT 
are  based  on  existing  tables  of  organization  and  projected  task  organizations  for 
all  MAGTFs. 

Measure:  Related  Systems  Training  Materials  (JTCW  and  EPLRS)  Adequate. 
Logistics 

Attribute:  Audio  and  Visual  Alert 
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Capability  Statement:  The  DACT  shall  provide  an  audio  and  visual  alert  of 
incoming  messages.  This  alert  shall  be  user  selectable:  audio,  visual,  both,  or  off. 
The  audio  alert  shall  have  a  volume  control. 

Measure:  Verify  audio  and  visual  alert  capability. 

Measure:  User  Selectable  On-Off  Capability. 

Measure:  User  Selectable  Volume  Control. 

Attribute:  Text  Scrolling  and  Graphics  Panning  Function 

Capability  Statement:  A  scrolling  or  paging  capability  shall  be  provided  for 
messages  that  exceed  the  display  capacity. 

Measure:  Verify  Text  Scrolling  Capability. 

Measure:  Verify  Graphics  Panning  Capability. 

Attribute:  Data  Input 

Capability  Statement:  The  DACT  shall  provide  the  capability  for  system  data 
input  and  control  using  a  pen  stylist  or  equivalent  device,  and  a  keyboard/keypad. 
Measure:  Keyboard  Adequate. 

Measure:  Pen  Stylus  Adequate. 
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